From rem-conf Thu Apr 01 05:45:17 1999 From rem-conf-request@es.net Thu Apr 01 05:45:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Ship-0005vu-00; Thu, 1 Apr 1999 05:41:27 -0800 Received: from cc603525-a.sumt1.nj.home.com (name) [24.3.178.241] by mail1.es.net with smtp (Exim 1.81 #2) id 10Shih-0005vR-00; Thu, 1 Apr 1999 05:41:20 -0800 From: Steve To: Message-Id: <419.436251.36187245smer@email.com> Subject: Dear Friend, Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Thu, 1 Apr 1999 05:41:20 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list $$$$ATTENTION $$$$ ATTENTION $$$$$ BEFORE YOU DELETE THIS OFFER, READ THIS REPORT!!! You can possibly earn $50,000 or more in 1999 by sending e-mail, seem impossible? Read on for details "AS SEEN ON NATIONAL T.V." Thank you for your time and Interest. Due to the popularity of this letter on the internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see, if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are, absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show has been truly remarkable. So many people are participating that those involved are doing, much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of lately. You will understand once you experience it. "HERE IT IS BELOW" ================================================ ================================================ *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days! Please read the enclosed program...THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This multi-level e-mail order marketing program works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the mid to late 1990's. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response – "That's why I'm sitting up here and you are all sitting out there!" The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out the full report to 100,000 e-mail addresses. The best thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, my only expense is my time. I am telling you like it is, I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 100,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work, you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS! I have retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 1,000,000...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent, IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in 1999. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere: This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if you don't order them). * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! * When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this advertisement and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their CA$H! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you copy every name and address ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. LISTED BELOW IS BY FAR THE FASTEST WAY TO SUCCESS !!!! METHOD #1: SENDING BULK E-MAIL Bulk e-mail is by far the best way to get your message out,with a fast response.After trying both the 2 step method and sending the full report, Sending the whole report WORKS BEST!! It is recommended to send out at the very least 100,000 e-mails.If money is tight,and you cannot afford to hire someone to send out the 100,000 e-mails,I encourage you to get in touch with others that have joined and SPLIT the cost with them. Once you have sent out your $5.00 to the four people listed below,someone will contact you to give you more information on this subject.As you start to receive orders FILL THEM RIGHT AWAY!!! IF YOU FOLLOW THE ABOVE TO THE LETTER THIS WILL BE THE RESULTS: Position 1 = 20 orders at $5.00 = $100 dollars. Position 2 = 20 get 20 = 400 at $5 = $2,000 dollars. At this point you have more then made back your bulk e-mail investment with extra money you need to pay cash for A top of the line bulk e-mailer. Plus hire yourself out to do bulk mailing for others who join Position 3 = 400 get 20 = 8000 at $5 = $40,000 dollars. Nice down on a new home,pay off debts,investments etc.etc.etc. Position 4 = 8000 get 20 = 160,000 at $5 = $800,000 BIG BUCKS !!!!! Quit your job and retire,spend your life loving your family and enjoying life like God intended for us. Even if this works with just 5 people you will still earn a decent amount of money. Once again your goal will be to encourage those who join and to work with them to see the BIG picture.Together as a team we will all benefit. As you can see with the above tried and proven method, You have the chance to earn ALOT MORE the the proposed $50,000. The key to SUCCESS WITH THIS PROGRAM IS TO GET YOUR FIRST 20, THEN STAY IN TOUCH WITH THEM. TEACH THEM AND WORK WITH THEM TO GET THEIR 20 TO GET 20 TO GET THEIR 20, RIGHT DOWN THE LINE!!!! OTHER ALTERNATIVE !! I have been involved with this marketing business for about 6 months,and have tried every way imaginable to make money with this venture. When I started I had no money to invest in bulk mailing so I went to different free ad sites and did the following. 1) I responded to each ad available with the following: PLEASE SEND ME MORE INFORMATION ABOUT YOUR BUSINESS. WHILE YOU ARE AT IT PLEASE TAKE A LOOK AT THE FOLLOWING BUSINESS PROPOSAL.BECAUSE YOU ARE ALREADY INVOLVED IN AN INTERNET BUSINESS,AFTER YOU READ IT FEEL FREE TO E-MAIL ME YOUR PROFESSIONAL OPINION. (COPY OF THE 10 PAGE REPORT) If you follow this method consistantly you will get the 20 people needed on your front line.The most important thing you can do is keep in constant contact with your front line to make sure they are promoting this venture consistantly to get their 20 people on their front line. If they are not then you will have to replace them as soon as possible. When I joined this program I was very new to the internet and had no help or advice from anyone in my immediate up line.If I had I,m sure this venture would have been more successful. Now that we are in a new year my goal is to teach others who are joining this venture to make CA$H MONEY in your MAILBOX EVERYDAY. AS SOON AS YOUR PLACE YOUR ORDERS WITH THE 4 PEOPLE LISTED BELOW, YOU WILL BE CONTACTED IN CASE YOU HAVE QUESTIONS OR NEED HELP TO GET STARTED. JOIN TODAY !!!!! ENJOY SUCCESS TOMORROW $$$$$$ SINCERELY, MARK GUERETTE ------------------------------------------ AVAILABLE REPORTS ------------------------------------------ *** Order Each REPORT by NUMBER and NAME *** Notes: - ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT CHEQUES NOT ACCEPTED - ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL - Make sure the cash is concealed by wrapping it in at least two sheets of paper. On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ REPORT #1 "THE INSIDER'S GUIDE TO ADVERTISING" ORDER REPORT #1 FROM: Steve Wolf PO BOX 912 Millburn,NJ 07041 $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ REPORT #2 "THE INSIDER'S GUIDE TO SENDING BULK E-MAIL ON THE INTERNET" ORDER REPORT #2 FROM: KENNETH MONTGOMERY 309 S. MISSION RD ENID OK 73703 $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ REPORT #3 "THE SECRETS TO MULTI-LEVEL MARKETING ON THE INTERNET" ORDER REPORT #3 FROM: GARY BALTZELL 1728 PARKSIDE PL IMPERIAL MO 63052 $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ REPORT #4 "HOW TO BECOME A MILLIONAIR UTILIZING THE POWER OF MULTI-LEVEL MARKETING AND THE INTERNET" ORDER REPORT #4 FROM: JEFF BASALYGA 1112 GLENWOOD DR. COLUMBIA TN 38401 $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ About 50,000 new people get online every month! ******* TIPS FOR SUCCESS ******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. You are selling a product which does not Cost anything to PRODUCE, SHIP OR ADVERTISE. 2. All of your customers pay you in CASH! 3. E-mail is without question the most powerful method of distributing information on earth. This program combines the distribution power of e-mail together with the revenue generating power of multi-level marketing. 4. Your only expenses other than your initial $20 investment is your time and the cost to send out 100,000 bulk e-mail! 5. Virtually all of the income you generate from this program is PURE PROFIT! 6. $$$$$$$$ SUCCESS IN 99 IS HERE NOW $$$ DO NOT PASS IT UP $$$$$$$$$ From rem-conf Thu Apr 01 14:20:27 1999 From rem-conf-request@es.net Thu Apr 01 14:20:25 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Spgw-0002Iu-00; Thu, 1 Apr 1999 14:12:02 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10Spgu-0002Ik-00; Thu, 1 Apr 1999 14:12:00 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Apr 1999 23:11:56 +0100 To: rem-conf@es.net Subject: Draft AVT minutes from Minneapolis Date: Thu, 01 Apr 1999 23:11:55 +0100 Message-ID: <1256.923004715@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Enclosed are draft minutes from the AVT working group meeting in Minneapolis. Please review these and send comments/corrections to me as soon as possible. Thanks, Colin ------------------------------------------------------------------------------- Minutes of the Audio/Video Transport Working Group Reported by Colin Perkins. The audio/video transport working group held two full meetings in Minneapolis and, in addition, a sub-group met to discuss the transport of MPEG-4 in a telephone conference with the MPEG committee meeting in Korea. Since the last meeting the group has published RFC2508 (IP/UDP/RTP header compression). The group does not currently have any drafts awaiting IESG approval for publication although some are now ready for working group last call. The revised RTP specification (draft-ietf-avt-rtp-new-03.txt) was presented by Steve Casner. Recent changes include a clarification that the payload type may change during a session, a review of sections 6.2 and 6.3 which resulted in several minor corrections and a removal of the requirement that inactive participant state is retained for 30 minutes (obsoleted by the reconsideration rules), and several corrections to the code in appendix A.7. The specification is now believed to be complete: all members of the working group are encouraged to read, check and comment on this document. The SSRC sampling draft (draft-ietf-avt-rtpsample-02.txt) is now complete except that the wording of the IPR statement has to be updated to match the guidelines in RFC2026. Once this is done it is intended to hold last call on this document for experimental status. The new RTCP conformance testing draft (draft-ietf-avt-rtcptest-00.txt) was presented by Jonathan Rosenberg. This describes several tests which may be performed on an RTP implementation to determine if it correctly implements the RTCP send/receive rules. Reaction to this draft was favourable, and a number of additional tests were noted for possible inclusion in a future version: check that SSRC identifiers are randomly allocated and check response to an SSRC collision. It was also noted that the draft assumes the default RTCP sender/receiver bandwidth fractions, and should be made more general. This document was adopted as an AVT work item, for eventual progression as an informational RFC. This draft also specifies the behavior of a software "test instrument" to be used in performing the tests; it would be a tremendous service to the working group if one or more members decided to implement this test instrument. Recent changes to the RTP A/V profile (draft-ietf-avt-profile-new-05.txt) were presented by Steve Casner. The use of MUST, SHOULD, MAY, etc, is now complete throughout the document, the possible use of a non-default RTCP bandwidth fraction is noted, a "changes from RFC1890" section has been added and the GSM-HR, GSM-EFR, QCELP, BT656, H263-1998 and BMPEG codecs have been added. The use of non-default RTCP bandwidth fractions requires the definition of appropriate SDP bandwidth modifiers. For example: b=RS: RTCP sender bandwidth b=RR: RTCP receiver bandwidth however it is noted that SDP allows for bandwidth modifiers to be expressed in kb/s as an integer only. The SDP specification must be updated either to allow bandwidth modifiers to be specified as being in b/s or to accept fractional values. Mark Handley expressed a preference for the former choice and no counter-arguments were given. It was agreed that the specification of these modifiers could simply be added to the RTP A/V profile, although since they may be of use in other profiles it may be better to start a new draft to record additions and changes to SDP. The new GSM payload formats are defined by reference to an ETSI document only, yet it is unclear whether this is acceptable. Concern was raised that a definition by reference made it difficult to find the information, yet copying the relevant tables into the profile raises the potential for inconsistency. A compromise was suggested whereby a copy of the format is included in the profile as an appendix for convenience, but it is noted that the ETSI document is authoritative. A first draft document registering the RTP codec names in the MIME namespace has been produced by Philipp Hoschka (draft-hoschka-rtp-mime-00.txt). This draft defines procedures for registration of codecs in the MIME namespace with "encoding considerations" specifying how they are transported in RTP; it also registers the existing codecs in the A/V profile. At present it's a rough draft needing completion. This draft is separate from the profile so that it may define procedures for carrying the codec data via more traditional MIME transports in addition to RTP; for example, draft-alvestrand-audio-l16-01.txt on the L16 codec should be merged into this draft. This draft is referenced by the revised profile draft, but if advancement of the profile to Draft Standard status would be blocked by a reference to this separate draft at Proposed Standard status, we may consider merging the new draft into the profile. Open issue: what to do with vnd.wave and vnd.avi types defined in RFC 2361? The A/V profile is now believed to be complete, once again careful review by the working group is requested. A revision to the PureVoice (QCELP) payload format has been produced in response to last call comments (draft-mckay-qcelp-02.txt). A new working group last call is now in progress on this draft - comments are solicited. The guidelines for writers of RTP payload format specifications draft (draft-ietf-avt-rtp-format-guidelines-01.txt) is now complete. Working group last call for BCP will be issued shortly. The RTP MIB (draft-ietf-rtp-mib-04.txt) was presented by Bill Strahm. Changes include: clarification of the difference between monitor and host implementations, explicit allowance of non-consecutive indexes into the rtpSessionEntry table, use of 32 bit rather than 16 bit indexes into this table, the removal of rtpSessionIfAddr and type change of rtpSessionIfIndex into InterfaceIndex rather than InterfaceIndexOrZero. There are two known issues with the current specification: the references need updating to match the most recent SNMP documents, and compatibility with IPv6 needs to be checked. With these two exceptions, the document is believed to be ready for last call for proposed standard. Comments from the working group are solicited. The generic FEC draft (draft-ietf-fec-05.txt) was presented by Jonathan Rosenberg. This revision clarifies usage with the RFC2198 payload format and defines SDP attributes for FEC protected media. Since the FEC data is sent as a separate stream from the media, it is represented in SDP by an additional "m=" line, with "a=fmtp" lines linking it to the media stream via "a=tag" directives, for example: m=audio 49170 RTP/AVP 0 -+ c=IN IP4 224.2.17.12/127 | Stream protected by FEC a=tag:1 -+ m=video 50274 RTP/AVP 31 m=audio 47182 RTP/AVP 121 -+ c=IN IP4 224.2.17.13/127 | FEC stream a=rtpmap:121 parityfec/8000 | a=fmtp:121 1 -+ It was suggested that this usage is unclear, since the FEC is really a content transfer encoding, rather than a new media type; a better solution may be to specify multiple "c=" lines for the media stream. Furthermore, it is unclear how to register parity FEC as a MIME type, since it can apply to both audio and video. One possibility is to register it as both "audio/parityfec" and "video/parityfec", another may be to define a new top level MIME type and register, say, "encoding/parityfec". If the solution of using multiple "c=" directives in the session description is chosen, the problem may be avoided since the MIME type will be that of the media stream, and the parity FEC becomes a MIME content-transfer-encoding instead. Finally, it was noted that the parity FEC work may be subject to a patent owned by 3com. The meeting received an assurance that the 3com would "license the patent in accordance with [rfc]2026", and it is expected that a formal IPR statement will be forthcoming. The parity FEC draft will be modified to note these issues. A more loss-tolerant payload format for MPEG (1 or 2) layer 1/2/3 audio (draft-finlayson-rtp-mp3-00.txt) was presented by Ross Finlayson. The existing payload format, RFC2250, is fine for layer 1 or 2 audio but is not optimal for layer 3 (.mp3) since frames are not ADUs in MP3 and are not independently decodable, and hence such a stream is not very loss tolerant. This new payload format is a data-preserving rearrangement of the original stream, such that each packet contains complete ADUs, not codec frames. This makes the stream more error resilient, although the implementation needs more knowledge of MPEG audio to perform the encoding. It was decided to make this new payload format a work item of AVT. A new payload format for DV format video (draft-kobayashi-dv-video-00.txt) was presented by Akimichi Ogawa. This format is straight-forward, with multiple blocks of the codec output (DIF blocks) being packed into an RTP packet with no format specific header. Audio and video are typically bundled (for a data rate of around 30Mbps), but may be transmitted separately if desired. Again, this will become an AVT work item. Open issues with this draft include the handling for the 12 bit sampling option for DV audio (a new payload format for 12 bit audio may be defined and referenced from the DV draft) and the definition of SDP attributes to describe DV sessions. A proposal to include location information in RTCP has presented by Jon Crowcroft (draft-crowcroft-rtcp-latlong-00.txt). This suggests defining an RTCP APP packet to include the real (or virtual) position of an RTP session participant in a media independent manner. Reaction to this was favourable, and it was suggested that the DNS LOC field has a definition for the format of a location description which could be reused. Also, it was suggested that this could be a new SDES packet type, rather than an APP packet. There was also concern expressed that RTCP would not be sufficiently timely to convey location information for fast moving sources - a solution more along the lines of the MPEG BIFS concept may be more appropriate there. A revised draft with more details is expected in time for the Oslo meeting. The RTP payload format for MPEG-4 streams (draft-ietf-avt-rtp-mpeg4-01.txt) was presented by Reha Civanlar and is a result of collaboration between AVT and the MPEG committee. The payload format maps MPEG-4 SL packets onto RTP in an efficient manner: those bits of the SL header which have a direct analogue in the RTP header are mapped onto the RTP header, whilst a payload header carries the additional features of the SL header. Open issues are the mapping between RTP streams and MPEG elementary stream identifiers (ESs), which will probably require definition of additional SDP attributes, and the transport of the initial object descriptor (IOD). It was suggested that a possible alternative for conveying the mapping between ESs and RTP streams would be via an RTCP SDES item, since conveying it in the session description will only work if the selection of SSRCs can be controlled. It was also noted that some applications do not send RTCP reports, so an initial out-of-band mapping may be needed. It is possible that a combination of the two approaches may make most sense. Concerns were also expressed that the transport of the IOD as part of the initial session description may be inappropriate. The IOD may be large, in which case it is wasteful to include it in a SAP announcement, and a URL may be more appropriate; in a SIP invitation it may sensible to include the complete IOD as a MIME multipart response or in the SDP response; a reference to a BIFS stream may also be possible. It may be that we cannot provide a single solution for communicating the IOD, and that the draft should give a list of examples of how this can be done, rather than defining a single solution, since it is clearly scenario dependent. Finally, transport of MPEG-4 streams requires a multiplexing solution (for reasons outlined in the draft). It was noted that the GeRM proposal (draft-ietf-avt-germ-00.txt) provides a good fit to these needs. Following the discussion of MPEG-4 transport, the group revisited the need for an RTP multiplexing scheme. The questions asked to focus this discussion were: should AVT standardize a multiplexing scheme? If yes, more than one scheme? Which one(s)? In addition, the chairs made a strawman proposal to standardize one scheme (GeRM) and recommend the use of Tmux (RFC1692) for other situations, noting that applications for which neither of these are satisfactory may specify their own multiplexing schemes, but that these would not need to be standardized by AVT. There was considerable discussion on the merits of this proposal, initially much of it regarding Tmux. Many people were concerned that Tmux is a new IP protocol which is not well supported and cannot be (easily) implemented at the application level (these are similar arguments to those for why RTP was not given its own protocol number). It was also noted that multiplexing gateways are likely to be dedicated systems, so the issue of IP protocol numbers is less of an issue. Concern was also expressed that Tmux does not compress headers although it does save on IP headers and reduce the packet count, whereas the other multiplexing proposals also include some form of header compression. Overall, the feeling of the meeting was that Tmux is not generally applicable for RTP multiplexing, and should not be one of our recommended solutions. There was considerably less dissent regarding the idea of using GeRM as our multiplexing protocol. It was noted that GeRM does not include the UDP port numbers, and that we may need to extend it to include these since they are needed in some cases to distinguish multiple streams. It was noted that we may wish to allow reduced complexity decoders which can only decode a subset of the GeRM functionality (for example, which can multiplex but not compress). This may also require SDP attributes to signal which subset of GeRM was being used by the sender. This may result in an additional section being added to the GeRM specification which describes the range of solutions, references Tmux, includes the non-compressed GeRM and SDP extensions. A number of comments were made that GeRM is too complex. These may be offset if it becomes clear that "profiles" of GeRM whereby applications may implement only a subset are acceptable. It was noted that compressed RTP (RFC2508) may also be applicable: if all that is required is to save the header overhead, then this will achieve the desired effect without the problems caused by multiplexing. The consensus of the group was that we should work with the current GeRM proposal as our starting point. GeRM solves the transport problem, we would prefer one solution, and the holes in the other proposals were worse than in GeRM. Try implementing GeRM for the proposed scenarios and see whether there are any serious limitations that can't be fixed and would justify creating another solution. The next agenda item was the generic payload format. Michael Speer noted that there is work underway to revise this format as discussed in the Los Angeles meeting, and it is expected that this will be complete before the Oslo meeting. Finally, the group discussed scaling RTCP for large groups. Concern has been expressed about the amount of router state used by RTCP in very large groups and it may be time to consider methods, other than SSRC sampling, and write some additional profiles to specify these other modes of operation. For example, the group has previously discussed sampling which receivers respond to probes by sending RTCP packets (sliding key scheme, as proposed by Bolot/Turletti/Wakeman), summarisation and aggregation of RTCP reports, and unicast reporting to the source which can then forward as multicast. Proposals for such extensions were solicited from the group. Interested parties should write new RTP profile drafts which may reference the existing A/V profile and just specify the differences. Mark Handley noted that there is work in the area of reliable multicast congestion control which may be applicable to RTP. The group is urged to follow this work, and to consider adding congestion control to their implementations. Anders Klemets noted an additional problem with RTCP reception reports where multiple unicast clients are reporting to a server. It is desired to have a way by which the server can cause the clients to report less often than their minimum interval interval to avoid being overloaded by the multiple reports (from unicast clients which aren't aware of each other). It was noted that this can be done by using an RTCP bandwidth modifier in the session description, but this is done at startup only and cannot vary dynamically. It was briefly noted, as the meeting closed, that the security area advisory has noted that DES encryption is insufficient, yet the RTP specification recommends the use of DES as a default. The group should consider changing this recommendation. The revised RTP spec already does refer to use of IPSEC, but defines the DES-based scheme for backward compatibility with existing implementations based on RFC 1889. ------------------------------------------------------------------------------- From rem-conf Thu Apr 01 16:36:30 1999 From rem-conf-request@es.net Thu Apr 01 16:36:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Sruc-0003wN-00; Thu, 1 Apr 1999 16:34:18 -0800 Received: from (siva.reelhosting.com) [216.89.67.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Srua-0003wD-00; Thu, 1 Apr 1999 16:34:16 -0800 X-Recipient: donal@aimware.com Date: Thu, 1 Apr 1999 18:27:39 -0800 (PST) X-Sender: genie@mrmailer.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) From: Genie Reply-To: genie@mrmailer.com To: (Dear Friend) Subject: ADV: I think you might find this useful... Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a responsible email being sent by K.M.A., 4401 Vineland Road, Orlando, FL 32811, Tel (407) 422-6784. Email remove@mrmailer.com. The above statement complies with Section 301 requirements relating to transmissions of unsolicited commercial electronic mail. To remove your name from our mailing list immediately, please refer to the statement at the bottom of this message. ---------------------------------------------------- Hi, Do you want more people to visit your web site? Learn how you can start receiving more traffic today! Visit us at http://www.trafficbuilder2000.com And for a limited time only, you can receive a FREE copy of the award winning ebook, "Web Promotion and Marketing". Hope to see you soon, Genie --------------- We are currently consolidating our many mailing lists and need to update our databases. Our records indicate that you may have inquired in the past. If this is not the case, please reply with "REMOVE" in the subject field to never receive email offers >from this vendor. From rem-conf Fri Apr 02 02:10:00 1999 From rem-conf-request@es.net Fri Apr 02 02:09:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10T0qd-00005O-00; Fri, 2 Apr 1999 02:06:47 -0800 Received: from nefeli.forthnet.gr [193.92.150.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10T0qb-00004u-00; Fri, 2 Apr 1999 02:06:45 -0800 Received: from g7s9y5 (assinik.ath.forthnet.gr [193.92.136.196]) by nefeli.forthnet.gr (8.8.5/8.8.5) with SMTP id UAA24600; Thu, 1 Apr 1999 20:37:29 +0300 (EET DST) Message-Id: <3.0.2.32.19990401204013.007aa5c0@popper.forthnet.gr> X-Sender: assinik.ath.forthnet.gr@popper.forthnet.gr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Thu, 01 Apr 1999 20:40:13 +0300 To: assinik@unipi.gr From: Nikitas Assimakopoulos Subject: NEW JOURNAL - CALL FOR PAPERS Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------------------------------------------------------------------------- We apologize if you receive this message more than once. ------------------------------------------------------------------------- NEW JOURNAL - CALL FOR PAPERS Title of the Journal : JOURNAL OF APPLIED SYSTEMS STUDIES Methodologies and Applications for Systems Approaches [ JASS ] AIMS AND SCOPE The mission of the "Journal of Applied Systems Studies" is on the development of methodologies based on the laws and rules of various sciences. New designs and functional methodologies are composed for applications in business, operational and social, as well as biological phenomena. The objectives of the "Journal of Applied Systems Studies" are to widespread the science of systems and present the research and application results of its domain. As the science rapidly changes and grows, resources and time become more precious, "Journal of Applied Systems Studies" provides the very best information and analysis to keep up to date with the latest developments and approaches to other scientific domains, through the application of systems approaches upon them.=20 The "Journal of Applied Systems Studies" aims to: =B7 To provide a forum for the exchange of experiences and information of studying the systems and the methodologies, tools and products used to design, measure and achieve it. =B7 To promote awareness of the crucial role of systems studies in the effective construction of the information systems developed, used, and/or maintained by organizations in pursuit of their business objectives. =B7 To provide a vehicle for the publication of academic papers related to all aspects of soft and hard system approaches. The "Journal of Applied Systems Studies" addresses all aspects of systemic analysis from both a practical and an academic viewpoint. It invites contributions from practitioners and academics, as well as national and international policy, standard making bodies, and sets out to be the definitive international reference source for such information. The readership of the "Journal of Applied Systems Studies" consists of academics, systems managers, computer scientists, information scientists, and researchers in applied system theory, as well as those involved in management, operations and political science in different scientific discipline i.e. Universities, Consulting Firms, Enterprises and Industries. Topics of Interest Topics of interest to JASS include, but are not limited to: =B7 Applications of cybernetics using the viable system model =B7 Applications of interactive planning methodology =B7 Applications of soft systems methodology =B7 Applied cybernetics in medicine =B7 Applied living systems =B7 Cognitive patterns =B7 Complex systems =B7 Conceptual systemic models =B7 Control systems =B7 Critical systems thinking =B7 Culture of peace =B7 Decision support systems =B7 Dynamical systems approaches =B7 Electronic service systems (Internet, Intranet, Extranet, Deltanet) =B7 Human-centered systems =B7 Human-computer interaction =B7 Intelligent systems engineering =B7 Intelligent tutoring systems =B7 Knowledge based systems =B7 Knowledge ecology =B7 Law systems =B7 Multimedia systems =B7 Problem structuring approaches =B7 Project management using systemic approaches =B7 Religious systems =B7 Semiotic approaches =B7 Social systems design =B7 Systemic metaphors =B7 Systemic reengineering =B7 Systems - metasystems and decisions - metadecisions =B7 Systems and design education =B7 Systems approaches for information systems =B7 Systems thinking for total quality management =B7 Total systems intervention =B7 Virtual communities We seek papers that improve on the best academic research or the best practical applications. Submitted papers should be motivated by the problems they address with compelling examples from real or potential applications. Systems papers must contain either a new methodology or interpreted results through well known methodology(ies) on real systems or simulations based on representative traces from real systems. Proposals for special issues, especially on emerging topics, are also welcome. EDITORIAL BOARD Editor-in-Chief : Nikitas A. Assimakopoulos, Department of Informatics, University of Piraeus, 80, Karaoli & Dimitriou Str., GR-185 34 Piraeus, Greece. Email : assinik@unipi.gr Honorary Editor : Bela H. Banathy, President of the International Federation for Systems Research & International Systems Institute, USA. Editor : Russell L. Ackoff, Chairman of the Board of INTERACT, USA. Associate Editors : William Acar, Kent State University, USA. Paul Ballonoff, Ballonoff Consulting, USA. Bela Antal Banathy, President of ISSS and International Systems Institute, USA. Michele Barbi, Istituto di Biofisica del C.N.R., Italy. Bernard De Baets, University of Gent, Belgium. Frantisek Carkovic, Slovak Academy of Sciences, Slovakia. Tony Chan, University of Aizu, Japan. Alexander Christakis, CWA, Ltd., Interactive Management Consultants, USA. John Darzentas, University of the Aegean, Greece. Martine Dodds, University of Stellenbosch, South Africa. Daniel Dubois, University of Liege, Belgium. Patrik Eklund, Umea University, Sweden. Peter Erdi, Academy of Sciences, Hungary. Marta Franova, Universite Paris Sud, France. Wojciech Gasparski, Polish Academy of Sciences, Poland. Ewa Grabska, Jagiellonian University, Poland. Raymond Ison, The Open University, UK. Gyuri Jaros, University of Sydney, Australia. Cliff Joslyn, Los Alamos National Laboratory, USA. John Karkazis, Athens University of Economics & Business, Greece. Manolya Kavakli, Istanbul Technical University, Turkey. Etienne Kerre, University of Gent, Belgium. Peter Kokol, University of Maribor, Slovenia. Petr Lansky, Academy of Sciences, Czech Republic. Brian Lees, University of Paisley, UK. Yi Lin, President and Director of the International Institute for General Systems Studies, China. Vladimir Marik, Czech Technical University, Czech Republic. Abraham Mehrez, Ben-Gurion University of the Negev, Israel. Fr. George Metallinos, University of Athens, Greece. Gerald Midgley, University of Hull, UK. Toshizumi Ohta, University of Electro-Communications, Japan. Anthony Panayotopoulos, University of Piraeus, Greece. Luis Rocha, Los Alamos National Laboratory, USA. James Rose, Ceptual Institute, USA. Gordon Rowland, Ithaca College, USA. Timothy K. Shih, Tamkang University, Taiwan, R.O.C. Ross Smith, Deakin University, Australia. Karl Svozil, University of Technology of Vienna, Austria. Steven Totosy de Zepentek, University of Alberta, Canada. Lane Tracy, Ohio University, USA. PUBLISHER "Cambridge International Science Publishing" , Cambridge, England. GUIDELINES FOR CONTRIBUTORS Authors should send to the Editor-in-Chief via email (assinik@unipi.gr) the paper in attached file(s) using "winzip32" for compression, with a description in the body of the message, and by post a printed copy along with the electronic file(s) submission on a 3=BD diskette which should conform the following requirements : 1. Manuscripts must be submitted in English and spelling should be adapted with The Concise Oxford Dictionary. Original papers (not published or not simultaneously submitted to another journal) will be reviewed by three anonymous referees. Upon acceptance of an article by the journal, the author(s) will be asked to transfer copyright of the article to the publisher which it will insure the widest possible dissemination of information under applicable copyright law.=20 2. The disk should be in IBM PC format; the files should be saved in Microsoft Word for PC, version 97 for Windows. Any other word-processing package will not be approved for submission. For artwork, figures and tables should only use the Ms-Office 97 package facilities and must be grouped and pasted, in the proper place, into the Word document.=20 3. Papers should be typed on one side of the paper. The pages should be numbered consecutively at the bottom centre of the page. The length of the paper should not exceed 10 journal pages (or about 5000 words), and hence manuscripts should not exceed 15 typed single-space A4 (printing area 14.7 x 24.7 cm) pages including title page, abstract, text, figures, tables and references. The number of artworks, figures and tables must be kept up to a minimum. Do not start a new page after the title information and abstract. Do not use tab for the first text line of each main section. Paragraphs should be both right and left justified. 4. The fonts (typeface) is Times New Roman. The text type size should be 11 points. Please use the page set-up command to ensure that your paper is prepared on A4 size paper (21 x 29.7 cm) using the default format for text and margins at the top and the bottom of the page for Microsoft Word 97. 5. The title should be written on the first line of the first page, left justified in upper and lower case letters (20-points bold). The authors' names should be left justified two lines below the full title in upper and lower case letters (14-points). Affiliation and mailing address (including email) should follow left justified also in upper and lower case letters (11-points).=20 6. Two lines below the author's name and affiliation start an abstract as the first paragraph of the paper. The abstract should follow the title, author's name, and mailing address on the first page (10-points) and must be up to 150 words. At the end of the abstract, skip a line and then, left justified, type "Keywords" (10-points bold) : followed by up to three (3) sets of words that describe the focus and contribution of the paper (10-points). The first set of keyword must be one of the topics of interest to JASS. Skip two lines and then begin the body of the paper (after an Introduction heading if required) immediately after the abstract. 7. All major headings are left justified. They are to be written in 12-points bold font and numbered consecutively followed by a period and the default tab, with Arabic numerals, e.g., 1. Introduction. Do not put a period after the text of the heading. Leave two lines above a major heading and one line before the start of the next paragraph or second-level heading. Subheadings are flush left in 11-points bold. There should be one line space before and after this level of heading. The paragraph should be numbered as a subsection of the previous major heading and the default tab e.g., 7.1 Subheadings. Sub-subheadings are flush left, in italics and in 11-points type. The paragraphs should be numbered as a sub-section of the previous subsection heading and the default tab e.g., 7.1.1 Sub-subheadings. There should be one line space before this level of heading and after this level of heading and the following paragraph. 8. The electronic version of the art should be included in the attached files and on the diskette, and it must be incoprorated into the word-processing file. Figures should be labeled in the text as "Figure x". Figure captions should be typed directly below the figure, in upper and lower case (11-points), and centred. 9. Table captions should be centered above the table. Tables should be included in the manuscript proper and referred to in the text as "Table x". 10. When numbering equations, enclose numbers in parenthesis ( ) and place them flush with the right-hand margin. Refer to them in the text as "Equation (x)". 11. Papers should be written without the use of footnotes. 12. Mathematical expressions and Greek or other symbols should be typed using the facilities of Ms-Word 97 and must be written clearly with ample spacing. Use the widely accepted symbols and abbreviations following the style of BS 1991 Part 2 1954. 13. All papers should end with a conclusion which summarizes the value of the work end, where appropriate, indicates possible directions for future developments. 14. References must be indicated in the text by brackets [ ]. Identify references in the text of the paper by typing the corresponding surname (or first surname) and year in brackets e.g.: [Aauthor (1998)]. They are listed alphabetically at the end of the paper under the major heading "References" (12-point bold font) left justified. List authors alphabetically by the first letter of the first author's surname name. Book titles and names of journals should be printed in italics. Please adopt the following style for references : Aauthor, A. (1998). Title of Book. XYZ Press, New York. Bauthor, B. and Aauthor, A. (1999). Title of Paper. Journal vol. 3(2), 1-20. Cauthor, C., Aauthor, A., Bauthor, B., and Jones, G. (1996). Title of Paper, in Title of Book, (E. Editor, ed.). XYZ Press, New York, 47-82. For multiple papers in the same year by the same author(s): Bauthor, B. and Aauthor, A. (1995A). Title of PaperA. JournalA vol. 3(5), 1-20. Bauthor, B. and Aauthor, A. (1995B). Title of PaperB. JournalB vol. 6(9), 56-80. 15. If material has been published elsewhere, authors must obtain the consent of the earlier publisher. Authors wishing to use material from the JASS should consult the Editor-in-Chief. From rem-conf Sun Apr 04 17:08:05 1999 From rem-conf-request@es.net Sun Apr 04 17:08:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10TwkI-0003cw-00; Sun, 4 Apr 1999 16:56:06 -0700 Received: from ppp1928.on.bellglobal.com (mail.mia.machine) [206.172.235.8] by mail1.es.net with smtp (Exim 1.81 #2) id 10TwkF-0003bo-00; Sun, 4 Apr 1999 16:56:03 -0700 From: Subject: FANTASY VACATION AD Date: Tue, 13 Apr 1999 06:42:15 Message-Id: Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Attention Miami Vacationers. Luxury Oceanside 2 bedroom Suite at World Famous "Alexander Hotel" in Miami Beach, Florida with Free Private Aircraft to Orlando, Key West, Bahamas or Naples (or your choice of destination), Free Limousine Service and Free use of our 60' Yacht. Prices starting at $3250 per week. Luxury Services International Inc. 800 7531992/954 9858303. fax 8004221535 to be removed email loadsoffun@eastmail.com From rem-conf Mon Apr 05 10:33:24 1999 From rem-conf-request@es.net Mon Apr 05 10:33:23 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UDAn-0001vV-00; Mon, 5 Apr 1999 10:28:33 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UDAl-0001vL-00; Mon, 5 Apr 1999 10:28:31 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id KAA31281; Mon, 5 Apr 1999 10:28:30 -0700 (PDT) Message-Id: <3.0.3.32.19990405102829.0090a530@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 05 Apr 1999 10:28:29 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 4/7 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar An Architecture for a Global Internet Host Distance Estimation Service Wednesday, April 7, 1999, 1:00-2:30 p.m. 405 Soda Hall Please note the time frame of the seminar series has changed!! Sugih Jamin Electrical Engineering and Computer Sciences, U of Michigan There is an increasing need for Internet hosts to be able to quickly and efficiently learn the distance, in terms of metrics such as latency or bandwidth, between Internet hosts. For example, to select the nearest of multiple equal-content web servers. This talk explores technical issues related to the creation of a public infrastructure service to provide such information. In so doing, we suggests an architecture, called IDMaps, whereby Internet distance information is distributed over the Internet, using IP multicast groups, in the form of a virtual distance map. Systems listening to the groups can estimate the distance between any pair of IP addresses by running a spanning tree algorithm over the received distance map. We also presents the results of experiments that give preliminary evidence supporting the architecture. This work thus lays the initial foundation for future work in this new area. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Mon Apr 05 13:21:10 1999 From rem-conf-request@es.net Mon Apr 05 13:21:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UFnt-0003sz-00; Mon, 5 Apr 1999 13:17:05 -0700 Received: from lrg-gw.lrg.ufsc.br (lrg.ufsc.br) [150.162.1.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UFnl-0003sT-00; Mon, 5 Apr 1999 13:17:01 -0700 Received: (from westphal@localhost) by lrg.ufsc.br (8.7.5/8.7.3) id QAA04397; Mon, 5 Apr 1999 16:40:47 -0300 (EST) Date: Mon, 5 Apr 1999 16:40:47 -0300 (EST) From: "Prof. Carlos B. Westphall" Message-Id: <199904051940.QAA04397@lrg.ufsc.br> To: Omar.Elloumi@enst-bretagne.fr, wwlu@ieee.org, lanoms99@lrg.ufsc.br Subject: IEEE LANOMS99 - Call for Papers Cc: bd_email@inesc.pt, ActiveNets_Wire@ittc.ukans.edu, issll@mercury.lcs.mit.edu, heads@hpovua.org, members@hpovua.org, 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, 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, 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, atm@sun.com, cost237-transport@comp.lancs.at, Hossam.Afifi@enst-bretagne.fr Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-MD5: sJC0bFf5Z4JdepwOCx028g== X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list *********** PLEASE, OBSERVE THE NEW DEADLINE MAY 06, 1999 = ************** **** I am sorry if you receive more than one copy of this e-mail = ********* *************************************************************************= ** LANOMS=B499 IEEE Latin American Network Operations and Management Symposium Rio de Janeiro - Brazil, December 03 - 04, 1999. =20 "NETWORK MANAGEMENT FOR THE NEW WORLD"=20 =20 Call for Papers =20 =20 The First Latin American Network Operations and Management Symposium -=20 LANOMS, to be held in Rio de Janeiro on the turn of the millennium=20 is the result of the great success of the events in the area of=20 network management known as NOMS and APNOMS. NOMS (Network Operations=20 and Management Symposium) was originally created ten years ago in=20 New Orleans, USA, and nowadays constitutes a worldwide event for=20 the researches in the area of network management. Recently, the=20 Asia/Pacific community promoted the APNOMS (Asia-Pacific=20 Network Operations and Management Symposium), which is an event more=20 oriented to the research and development community in that continent.=20 Within this context, we will promote the first LANOMS=20 (http://www.lrg.ufsc.br/~lanoms99) in order to stimulate the=20 researches in Latin America. It is important to emphasize that this event will be held in the same hotel and two days before the=20 GLOBECOM. In the last few years, we have been witnessing an increasing demand on=20 topics associated with Network Management in national and international=20 events, organized mainly in Brazil, Mexico, Chile, Argentina, and = Uruguay.=20 As a consequence, we observed in Latin America a solid necessity of a=20 specific event where there might be room to debate the main issues = involving the=20 area of Network Management. For obvious reasons, the organization of=20 LANOMS will be tuned with NOMS and APNOMS to even stimulate the = participation=20 of the Latin American community in these events. As LANOMS derives from NOMS, keeping its original characteristics, it will create a forum=20 which is more specific to the requirements of Latin America in the area of Network Management involving telecommunication companies,=20 academic institutions, service providers and equipment vendors. Although organized in Latin America, LANOMS will be opened to participants=20 (researchers, developers, investors, etc) from other continents who are interested in having, or already have, research or commercial=20 liaisons in Latin America. The objectives of LANOMS include, but are not limited to: * to satisfy an increasing necessity of organizing a specific=20 event on network management in Latin America in order to=20 divulge the researches currently developed; * to identify the problems and solutions specific to the area=20 of network management; * to make viable the solutions proposed by the international=20 community to Latin America and vice-versa; and=20 * to expose the potentialities of the Network Management area; Submissions should be complete, full-length papers and should not exceed = =20 12 pages. Electronic submission of papers is strongly encouraged. Full=20 instructions for the electronic submissions will be available soon on = the LANOMS web page.=20 Important Dates: Paper due: May 06, 1999 Notification: Aug. 06, 1999 Camera Ready: Sep. 06, 1999 Suggested Topics: + Artificial Intelligence Solutions for Network Management + Broadband Network Management Implementation + Business and Service Management + CORBA Support for Distributed Management + Distributed Network and Service Management + Enterprise Management + Experiences in Management Environments + Intelligent Agents + Interoperability and Platforms + Network Operation and Management Solutions for Latin America + Neural Networks Technologies + New Technologies and Methodologies + Proactive Management + Protocol Specifications + SONET/SDH/ATM + Security Management + Telecommunication Policies + Traffic and Performance Management + TMN Technology + Web-Based Management=20 Committee Members --------- ------- General and TCP Chair: =20 Carlos Becker Westphall, Brazil=20 =20 TPC Co-Chairs: =20 Luiz Fernando Kormann, Brazil=20 Mirela Sechi Moretti Annoni Notare, Brazil=20 =20 Publication Chair: =20 Bernardo Goncalves Riso, Brazil=20 =20 Publicity Chair: =20 Juan Carlos Miguez, Uruguay=20 =20 Finance Chair: =20 Fernando Augusto da Silva Cruz, Brazil=20 Joao Bosco Mangueira Sobral, Brazil=20 =20 Local Arrangements Chair: =20 Michael Stanton, Brazil =20 =20 IEEE CNOM Officer:=20 Veli Sahin, USA=20 =20 International Liasions:=20 Africa: J. Roos, South Africa=20 Asia: J. Hong, Korea =20 Europe: E. Bagnasco, Italy =20 N. America: S. Aidarous, USA =20 Oceania: P. Ray, Australia =20 =20 Advisory Board:=20 B. Meandzijas, USA=20 D. Zuckermann, USA=20 M. Ejiri, Japan=20 M. Yoshida, Japan=20 R. Saracco, Italy=20 S. Goyal, USA=20 W. Zimmer, Germany=20 =20 Technical Program Committee=20 Adarsh Sethi (USA)=20 Alan Mckinlay (UK)=20 Alejandro Miralles (Chile) Behcet Sarikaya (Japan)=20 Carlos de Lara (Mexico)=20 Carlos E. Caicedo (Colombia)=20 Eduard Pinnes (USA)=20 Edmundo R. Madeira (Brazil)=20 Elias Procopio Duarte Junior (Brazil)=20 Gabriel Jakobson (USA)=20 German Goldszmidt (USA)=20 Guy Pujolle (France) =20 Heinz-Gerd Hegering (Germany)=20 Joberto S. Barbosa Martins (Brazil)=20 Jong-Tae Park (Korea)=20 Jose Marcos Nogueira (Brazil)=20 Jose Neuman de Souza (Brazil)=20 Keith-Stuart von Mecklenburg (UK)=20 Leonor W. Chaux (Colombia)=20 Manu Malek (USA)=20 Manoel C. Penna (Brazil) =20 Michael Bauer (Canada)=20 Michele Sibilla (France)=20 Nelson Fonseca (Brazil)=20 Osvaldo Bianchi (Argentina)=20 Paulo Gomide Cohn (Brazil)=20 Raul Monge (Chile)=20 Robert Weihmayer (USA)=20 Roberto Vercelli (Italy) =20 Varoozh Harikian (Belgium)=20 =20 This event is Technically Co-Sponsored by the IEEE ComSoc. Contact Address: Carlos Becker Westphall (LANOMS=B499 General Chair) Federal University of Santa Catarina - UFSC Technological Center - CTC Network and Management Laboratory - LRG P.O.Box 476=20 88040 970 Florianopolis - SC BRAZIL lanoms99@lrg.ufsc.br =20 http://www.lrg.ufsc.br/~lanoms99 From rem-conf Mon Apr 05 14:17:43 1999 From rem-conf-request@es.net Mon Apr 05 14:17:41 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UGhj-00050S-00; Mon, 5 Apr 1999 14:14:47 -0700 Received: from lrg-gw.lrg.ufsc.br (lrg.ufsc.br) [150.162.1.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UGhe-00050I-00; Mon, 5 Apr 1999 14:14:43 -0700 Received: (from westphal@localhost) by lrg.ufsc.br (8.7.5/8.7.3) id RAA05026; Mon, 5 Apr 1999 17:28:24 -0300 (EST) Date: Mon, 5 Apr 1999 17:28:24 -0300 (EST) From: "Prof. Carlos B. Westphall" Message-Id: <199904052028.RAA05026@lrg.ufsc.br> To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, commsoft@cc.bellcore.com, comsoc-chapters@IEEE.ORG, comsoc-gicb@IEEE.ORG, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, enternet@BBN.COM, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, isadsoc@fokus.gmd.de, itc@fokus.gmd.de, kia@usl.edu, multicomm@cc.bellcore.com, osimcast@BBN.COM, performance@haven.epm.ornl.gov, rem-conf@es.net, reres@laas.fr, sb.all@IEEE.ORG, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@IEEE.ORG, xtp-relay@cs.concordia.ca, ekpark@cstp.umkc.edu Subject: IEEE LANOMS99 - Call for Papers Cc: lanoms99@lrg.ufsc.br Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-MD5: uX8w20BO4ptyhhosWSXamg== X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list *********** PLEASE, OBSERVE THE NEW DEADLINE MAY 06, 1999 = ************** **** I am sorry if you receive more than one copy of this e-mail = ********* *************************************************************************= ** LANOMS=B499 IEEE Latin American Network Operations and Management Symposium Rio de Janeiro - Brazil, December 03 - 04, 1999. =20 "NETWORK MANAGEMENT FOR THE NEW WORLD"=20 =20 Call for Papers =20 =20 The First Latin American Network Operations and Management Symposium -=20 LANOMS, to be held in Rio de Janeiro on the turn of the millennium=20 is the result of the great success of the events in the area of=20 network management known as NOMS and APNOMS. NOMS (Network Operations=20 and Management Symposium) was originally created ten years ago in=20 New Orleans, USA, and nowadays constitutes a worldwide event for=20 the researches in the area of network management. Recently, the=20 Asia/Pacific community promoted the APNOMS (Asia-Pacific=20 Network Operations and Management Symposium), which is an event more=20 oriented to the research and development community in that continent.=20 Within this context, we will promote the first LANOMS=20 (http://www.lrg.ufsc.br/~lanoms99) in order to stimulate the=20 researches in Latin America. It is important to emphasize that this event will be held in the same hotel and two days before the=20 GLOBECOM. In the last few years, we have been witnessing an increasing demand on=20 topics associated with Network Management in national and international=20 events, organized mainly in Brazil, Mexico, Chile, Argentina, and = Uruguay.=20 As a consequence, we observed in Latin America a solid necessity of a=20 specific event where there might be room to debate the main issues = involving the=20 area of Network Management. For obvious reasons, the organization of=20 LANOMS will be tuned with NOMS and APNOMS to even stimulate the = participation=20 of the Latin American community in these events. As LANOMS derives from NOMS, keeping its original characteristics, it will create a forum=20 which is more specific to the requirements of Latin America in the area of Network Management involving telecommunication companies,=20 academic institutions, service providers and equipment vendors. Although organized in Latin America, LANOMS will be opened to participants=20 (researchers, developers, investors, etc) from other continents who are interested in having, or already have, research or commercial=20 liaisons in Latin America. The objectives of LANOMS include, but are not limited to: * to satisfy an increasing necessity of organizing a specific=20 event on network management in Latin America in order to=20 divulge the researches currently developed; * to identify the problems and solutions specific to the area=20 of network management; * to make viable the solutions proposed by the international=20 community to Latin America and vice-versa; and=20 * to expose the potentialities of the Network Management area; Submissions should be complete, full-length papers and should not exceed = =20 12 pages. Electronic submission of papers is strongly encouraged. Full=20 instructions for the electronic submissions will be available soon on = the LANOMS web page.=20 Important Dates: Paper due: May 06, 1999 Notification: Aug. 06, 1999 Camera Ready: Sep. 06, 1999 Suggested Topics: + Artificial Intelligence Solutions for Network Management + Broadband Network Management Implementation + Business and Service Management + CORBA Support for Distributed Management + Distributed Network and Service Management + Enterprise Management + Experiences in Management Environments + Intelligent Agents + Interoperability and Platforms + Network Operation and Management Solutions for Latin America + Neural Networks Technologies + New Technologies and Methodologies + Proactive Management + Protocol Specifications + SONET/SDH/ATM + Security Management + Telecommunication Policies + Traffic and Performance Management + TMN Technology + Web-Based Management=20 Committee Members --------- ------- General and TCP Chair: =20 Carlos Becker Westphall, Brazil=20 =20 TPC Co-Chairs: =20 Luiz Fernando Kormann, Brazil=20 Mirela Sechi Moretti Annoni Notare, Brazil=20 =20 Publication Chair: =20 Bernardo Goncalves Riso, Brazil=20 =20 Publicity Chair: =20 Juan Carlos Miguez, Uruguay=20 =20 Finance Chair: =20 Fernando Augusto da Silva Cruz, Brazil=20 Joao Bosco Mangueira Sobral, Brazil=20 =20 Local Arrangements Chair: =20 Michael Stanton, Brazil =20 =20 IEEE CNOM Officer:=20 Veli Sahin, USA=20 =20 International Liasions:=20 Africa: J. Roos, South Africa=20 Asia: J. Hong, Korea =20 Europe: E. Bagnasco, Italy =20 N. America: S. Aidarous, USA =20 Oceania: P. Ray, Australia =20 =20 Advisory Board:=20 B. Meandzijas, USA=20 D. Zuckerman, USA=20 M. Ejiri, Japan=20 M. Yoshida, Japan=20 R. Saracco, Italy=20 S. Goyal, USA=20 W. Zimmer, Germany=20 =20 Technical Program Committee=20 Adarsh Sethi (USA)=20 Alan Mckinlay (UK)=20 Alejandro Miralles (Chile) Behcet Sarikaya (Japan)=20 Carlos de Lara (Mexico)=20 Carlos E. Caicedo (Colombia)=20 Eduard Pinnes (USA)=20 Edmundo R. Madeira (Brazil)=20 Elias Procopio Duarte Junior (Brazil)=20 Gabriel Jakobson (USA)=20 German Goldszmidt (USA)=20 Guy Pujolle (France) =20 Heinz-Gerd Hegering (Germany)=20 Joberto S. Barbosa Martins (Brazil)=20 Jong-Tae Park (Korea)=20 Jose Marcos Nogueira (Brazil)=20 Jose Neuman de Souza (Brazil)=20 Keith-Stuart von Mecklenburg (UK)=20 Leonor W. Chaux (Colombia)=20 Manu Malek (USA)=20 Manoel C. Penna (Brazil) =20 Michael Bauer (Canada)=20 Michele Sibilla (France)=20 Nelson Fonseca (Brazil)=20 Osvaldo Bianchi (Argentina)=20 Paulo Gomide Cohn (Brazil)=20 Raul Monge (Chile)=20 Robert Weihmayer (USA)=20 Roberto Vercelli (Italy) =20 Varoozh Harikian (Belgium)=20 =20 This event is Technically Co-Sponsored by the IEEE ComSoc. Contact Address: Carlos Becker Westphall (LANOMS=B499 General Chair) Federal University of Santa Catarina - UFSC Technological Center - CTC Network and Management Laboratory - LRG P.O.Box 476=20 88040 970 Florianopolis - SC BRAZIL lanoms99@lrg.ufsc.br =20 http://www.lrg.ufsc.br/~lanoms99 From rem-conf Mon Apr 05 14:55:51 1999 From rem-conf-request@es.net Mon Apr 05 14:55:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UHJ4-00061B-00; Mon, 5 Apr 1999 14:53:22 -0700 Received: from relay2.faa.gov [204.108.10.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UHJ3-000611-00; Mon, 5 Apr 1999 14:53:21 -0700 Received: from faa.gov ([192.168.254.2]) by relay2.faa.gov (Pro-8.9.3/Pro-8.9.3) with SMTP id RAA23608; Mon, 5 Apr 1999 17:47:14 -0400 (EDT) Received: from POP3 Client by faa.gov (ccMail Link to SMTP R8.20.00.25) id AA923347468; Mon, 05 Apr 1999 17:40:43 -0500 Message-Id: <9904059233.AA923347468@faa.gov> X-Mailer: ccMail Link to SMTP R8.20.00.25 Date: Mon, 05 Apr 1999 16:40:47 -0500 From: "Prof. Carlos B. Westphall" To: , , Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: IEEE LANOMS99 - Call for Papers MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --simple boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable *********** PLEASE=2C OBSERVE THE NEW DEADLINE MAY 06=2C 1999 ******= ******** **** I am sorry if you receive more than one copy of this e-mail *****= **** ***********************************************************************= **** LANOMS=B499 IEEE Latin American Network Operations and Management Symposium Rio de Janeiro - Brazil=2C December 03 - 04=2C 1999=2E =20 "NETWORK MANAGEMENT FOR THE NEW WORLD=22=20 =20 Call for Papers =20 =20 The First Latin American Network Operations and Management Symposium - = LANOMS=2C to be held in Rio de Janeiro on the turn of the millennium=20= =0Ais the result of the great success of the events in the area of=20 network management known as NOMS and APNOMS=2E NOMS (Network Operations= =20 and Management Symposium=29 was originally created ten years ago in=20 New Orleans=2C USA=2C and nowadays constitutes a worldwide event for=20= =0Athe researches in the area of network management=2E Recently=2C the = Asia=2FPacific community promoted the APNOMS (Asia-Pacific=20 Network Operations and Management Symposium=29=2C which is an event mor= e=20 oriented to the research and development community in that continent=2E= =20 Within this context=2C we will promote the first LANOMS=20 =28http=3A=2F=2Fwww=2Elrg=2Eufsc=2Ebr=2F~lanoms99=29 in order to stimul= ate the=20 researches in Latin America=2E It is important to emphasize that this event will be held in the same hotel and two days before the = GLOBECOM=2E In the last few years=2C we have been witnessing an increasing demand o= n=20 topics associated with Network Management in national and international= =20 events=2C organized mainly in Brazil=2C Mexico=2C Chile=2C Argentina=2C= and Uruguay=2E=20 As a consequence=2C we observed in Latin America a solid necessity of a= =20 specific event where there might be room to debate the main issues invo= lving the=20 area of Network Management=2E For obvious reasons=2C the organization o= f=20 LANOMS will be tuned with NOMS and APNOMS to even stimulate the partici= pation=20 of the Latin American community in these events=2E As LANOMS derives fr= om NOMS=2C keeping its original characteristics=2C it will create a forum = which is more specific to the requirements of Latin America in the area= of Network Management involving telecommunication companies=2C=20 academic institutions=2C service providers and equipment vendors=2E Alt= hough organized in Latin America=2C LANOMS will be opened to participants=20 =28researchers=2C developers=2C investors=2C etc=29 from other continen= ts who are interested in having=2C or already have=2C research or commerci= al=20 liaisons in Latin America=2E The objectives of LANOMS include=2C but ar= e not limited to=3A * to satisfy an increasing necessity of organizing a specific=20= =0A event on network management in Latin America in order to=20= =0A divulge the researches currently developed=3B * to identify the problems and solutions specific to the area=20= =0A of network management=3B * to make viable the solutions proposed by the international=20= =0A community to Latin America and vice-versa=3B and=20 * to expose the potentialities of the Network Management area=3B= Submissions should be complete=2C full-length papers and should not exc= eed =20 12 pages=2E Electronic submission of papers is strongly encouraged=2E = Full=20 instructions for the electronic submissions will be available soon on t= he LANOMS web page=2E=20 Important Dates=3A Paper due=3A May 06=2C 1999 Notification=3A Aug=2E 06=2C 1999 Camera Ready=3A Sep=2E 06=2C 1999 Suggested Topics=3A + Artificial Intelligence Solutions for Network Management + Broadband Network Management Implementation + Business and Service Management + CORBA Support for Distributed Management + Distributed Network and Service Management + Enterprise Management + Experiences in Management Environments + Intelligent Agents + Interoperability and Platforms + Network Operation and Management Solutions for Latin America + Neural Networks Technologies + New Technologies and Methodologies + Proactive Management + Protocol Specifications + SONET=2FSDH=2FATM + Security Management + Telecommunication Policies + Traffic and Performance Management + TMN Technology + Web-Based Management=20 Committee Members --------- ------- General and TCP Chair=3A =20 Carlos Becker Westphall=2C Brazil=20 =20 TPC Co-Chairs=3A =20 Luiz Fernando Kormann=2C Brazil=20 Mirela Sechi Moretti Annoni Notare=2C Brazil=20 =20 Publication Chair=3A =20 Bernardo Goncalves Riso=2C Brazil=20 =20 Publicity Chair=3A =20 Juan Carlos Miguez=2C Uruguay=20 =20 Finance Chair=3A =20 Fernando Augusto da Silva Cruz=2C Brazil=20 Joao Bosco Mangueira Sobral=2C Brazil=20 =20 Local Arrangements Chair=3A =20 Michael Stanton=2C Brazil =20 =20 IEEE CNOM Officer=3A=20 Veli Sahin=2C USA=20 =20 International Liasions=3A=20 Africa=3A J=2E Roos=2C South Africa Asia=3A J=2E Hong=2C Korea =20 Europe=3A E=2E Bagnasco=2C Italy =20 N=2E America=3A S=2E Aidarous=2C USA =20 Oceania=3A P=2E Ray=2C Australia =20 =20 Advisory Board=3A=20 B=2E Meandzijas=2C USA=20 D=2E Zuckermann=2C USA=20 M=2E Ejiri=2C Japan=20 M=2E Yoshida=2C Japan=20 R=2E Saracco=2C Italy=20 S=2E Goyal=2C USA=20 W=2E Zimmer=2C Germany=20 =20 Technical Program Committee=20 Adarsh Sethi (USA=29=20 Alan Mckinlay (UK=29=20 Alejandro Miralles (Chile=29 Behcet Sarikaya (Japan=29=20 Carlos de Lara (Mexico=29=20 Carlos E=2E Caicedo (Colombia=29=20 Eduard Pinnes (USA=29=20 Edmundo R=2E Madeira (Brazil=29=20 Elias Procopio Duarte Junior (Brazil=29=20 Gabriel Jakobson (USA=29=20 German Goldszmidt (USA=29=20 Guy Pujolle (France=29 =20 Heinz-Gerd Hegering (Germany=29=20 Joberto S=2E Barbosa Martins (Brazil=29=20 Jong-Tae Park (Korea=29=20 Jose Marcos Nogueira (Brazil=29=20 Jose Neuman de Souza (Brazil=29=20 Keith-Stuart von Mecklenburg (UK=29=20 Leonor W=2E Chaux (Colombia=29=20 Manu Malek (USA=29=20 Manoel C=2E Penna (Brazil=29 =20 Michael Bauer (Canada=29=20 Michele Sibilla (France=29=20 Nelson Fonseca (Brazil=29=20 Osvaldo Bianchi (Argentina=29=20 Paulo Gomide Cohn (Brazil=29=20 Raul Monge (Chile=29=20 Robert Weihmayer (USA=29=20 Roberto Vercelli (Italy=29 =20 Varoozh Harikian (Belgium=29=20 =20 This event is Technically Co-Sponsored by the IEEE ComSoc=2E Contact Address=3A Carlos Becker Westphall (LANOMS=B499 General Chair=29 Federal University of Santa Catarina - UFSC Technological Center - CTC Network and Management Laboratory - LRG P=2EO=2EBox 476=20 88040 970 Florianopolis - SC BRAZIL lanoms99=40lrg=2Eufsc=2Ebr =20 http=3A=2F=2Fwww=2Elrg=2Eufsc=2Ebr=2F~lanoms99 =20 = --simple boundary-- From rem-conf Mon Apr 05 15:47:09 1999 From rem-conf-request@es.net Mon Apr 05 15:47:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UI7x-0007CZ-00; Mon, 5 Apr 1999 15:45:57 -0700 Received: from relay2.faa.gov [204.108.10.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UI7v-0007CP-00; Mon, 5 Apr 1999 15:45:55 -0700 Received: from faa.gov ([192.168.254.2]) by relay2.faa.gov (Pro-8.9.3/Pro-8.9.3) with SMTP id SAA26852; Mon, 5 Apr 1999 18:41:06 -0400 (EDT) Received: from POP3 Client by faa.gov (ccMail Link to SMTP R8.20.00.25) id AA923351581; Mon, 05 Apr 1999 18:34:36 -0500 Message-Id: <9904059233.AA923351581@faa.gov> X-Mailer: ccMail Link to SMTP R8.20.00.25 Date: Mon, 05 Apr 1999 16:40:47 -0500 From: "Prof. Carlos B. Westphall" To: , , Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: IEEE LANOMS99 - Call for Papers MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --simple boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable *********** PLEASE=2C OBSERVE THE NEW DEADLINE MAY 06=2C 1999 ******= ******** **** I am sorry if you receive more than one copy of this e-mail *****= **** ***********************************************************************= **** LANOMS=B499 IEEE Latin American Network Operations and Management Symposium Rio de Janeiro - Brazil=2C December 03 - 04=2C 1999=2E =20 "NETWORK MANAGEMENT FOR THE NEW WORLD=22=20 =20 Call for Papers =20 =20 The First Latin American Network Operations and Management Symposium - = LANOMS=2C to be held in Rio de Janeiro on the turn of the millennium is= the result of the great success of the events in the area of=20 network management known as NOMS and APNOMS=2E NOMS (Network Operations= =20 and Management Symposium=29 was originally created ten years ago in=20 New Orleans=2C USA=2C and nowadays constitutes a worldwide event for th= e researches in the area of network management=2E Recently=2C the=20 Asia=2FPacific community promoted the APNOMS (Asia-Pacific=20 Network Operations and Management Symposium=29=2C which is an event mor= e=20 oriented to the research and development community in that continent=2E= =20 Within this context=2C we will promote the first LANOMS=20 =28http=3A=2F=2Fwww=2Elrg=2Eufsc=2Ebr=2F~lanoms99=29 in order to stimul= ate the=20 researches in Latin America=2E It is important to emphasize that this event will be held in the same hotel and two days before the = GLOBECOM=2E In the last few years=2C we have been witnessing an increasing demand o= n=20 topics associated with Network Management in national and international= =20 events=2C organized mainly in Brazil=2C Mexico=2C Chile=2C Argentina=2C= and Uruguay=2E=20 As a consequence=2C we observed in Latin America a solid necessity of a= =20 specific event where there might be room to debate the main issues invo= lving the=20 area of Network Management=2E For obvious reasons=2C the organization o= f=20 LANOMS will be tuned with NOMS and APNOMS to even stimulate the partici= pation=20 of the Latin American community in these events=2E As LANOMS derives fr= om NOMS=2C keeping its original characteristics=2C it will create a forum = which is more specific to the requirements of Latin America in the area= of Network Management involving telecommunication companies=2C=20 academic institutions=2C service providers and equipment vendors=2E Alt= hough organized in Latin America=2C LANOMS will be opened to participants=20 =28researchers=2C developers=2C investors=2C etc=29 from other continen= ts who are interested in having=2C or already have=2C research or commerci= al=20 liaisons in Latin America=2E The objectives of LANOMS include=2C but ar= e not limited to=3A * to satisfy an increasing necessity of organizing a specific = event on network management in Latin America in order to = divulge the researches currently developed=3B * to identify the problems and solutions specific to the area = of network management=3B * to make viable the solutions proposed by the international = community to Latin America and vice-versa=3B and=20 * to expose the potentialities of the Network Management area=3B= Submissions should be complete=2C full-length papers and should not exc= eed =20 12 pages=2E Electronic submission of papers is strongly encouraged=2E = Full=20 instructions for the electronic submissions will be available soon on t= he LANOMS web page=2E=20 Important Dates=3A Paper due=3A May 06=2C 1999 Notification=3A Aug=2E 06=2C 1999 Camera Ready=3A Sep=2E 06=2C 1999 Suggested Topics=3A + Artificial Intelligence Solutions for Network Management + Broadband Network Management Implementation + Business and Service Management + CORBA Support for Distributed Management + Distributed Network and Service Management + Enterprise Management + Experiences in Management Environments + Intelligent Agents + Interoperability and Platforms + Network Operation and Management Solutions for Latin America + Neural Networks Technologies + New Technologies and Methodologies + Proactive Management + Protocol Specifications + SONET=2FSDH=2FATM + Security Management + Telecommunication Policies + Traffic and Performance Management + TMN Technology + Web-Based Management=20 Committee Members --------- ------- General and TCP Chair=3A =20 Carlos Becker Westphall=2C Brazil=20 =20 TPC Co-Chairs=3A =20 Luiz Fernando Kormann=2C Brazil=20 Mirela Sechi Moretti Annoni Notare=2C Brazil=20 =20 Publication Chair=3A =20 Bernardo Goncalves Riso=2C Brazil=20 =20 Publicity Chair=3A =20 Juan Carlos Miguez=2C Uruguay=20 =20 Finance Chair=3A =20 Fernando Augusto da Silva Cruz=2C Brazil=20 Joao Bosco Mangueira Sobral=2C Brazil=20 =20 Local Arrangements Chair=3A =20 Michael Stanton=2C Brazil =20 =20 IEEE CNOM Officer=3A=20 Veli Sahin=2C USA=20 =20 International Liasions=3A=20 Africa=3A J=2E Roos=2C South Africa=20 Asia=3A J=2E Hong=2C Korea =20 Europe=3A E=2E Bagnasco=2C Italy =20 N=2E America=3A S=2E Aidarous=2C USA =20 Oceania=3A P=2E Ray=2C Australia =20 =20 Advisory Board=3A=20 B=2E Meandzijas=2C USA=20 D=2E Zuckermann=2C USA=20 M=2E Ejiri=2C Japan=20 M=2E Yoshida=2C Japan=20 R=2E Saracco=2C Italy=20 S=2E Goyal=2C USA=20 W=2E Zimmer=2C Germany=20 =20 Technical Program Committee=20 Adarsh Sethi (USA=29=20 Alan Mckinlay (UK=29=20 Alejandro Miralles (Chile=29 Behcet Sarikaya (Japan=29=20 Carlos de Lara (Mexico=29=20 Carlos E=2E Caicedo (Colombia=29=20 Eduard Pinnes (USA=29=20 Edmundo R=2E Madeira (Brazil=29 Elias Procopio Duarte Junior (Brazil=29=20 Gabriel Jakobson (USA=29=20 German Goldszmidt (USA=29=20 Guy Pujolle (France=29 =20 Heinz-Gerd Hegering (Germany=29=20 Joberto S=2E Barbosa Martins (Brazil=29=20 Jong-Tae Park (Korea=29=20 Jose Marcos Nogueira (Brazil=29=20 Jose Neuman de Souza (Brazil=29=20 Keith-Stuart von Mecklenburg (UK=29=20 Leonor W=2E Chaux (Colombia=29=20 Manu Malek (USA=29=20 Manoel C=2E Penna (Brazil=29 =20 Michael Bauer (Canada=29=20 Michele Sibilla (France=29=20 Nelson Fonseca (Brazil=29=20 Osvaldo Bianchi (Argentina=29=20 Paulo Gomide Cohn (Brazil=29=20 Raul Monge (Chile=29=20 Robert Weihmayer (USA=29=20 Roberto Vercelli (Italy=29 =20 Varoozh Harikian (Belgium=29=20 =20 This event is Technically Co-Sponsored by the IEEE ComSoc=2E Contact Address=3A Carlos Becker Westphall (LANOMS=B499 General Chair=29 Federal University of Santa Catarina - UFSC Technological Center - CTC Network and Management Laboratory - LRG P=2EO=2EBox 476=20 88040 970 Florianopolis - SC BRAZIL lanoms99=40lrg=2Eufsc=2Ebr =20 http=3A=2F=2Fwww=2Elrg=2Eufsc=2Ebr=2F~lanoms99 =20 = --simple boundary-- From rem-conf Mon Apr 05 16:53:57 1999 From rem-conf-request@es.net Mon Apr 05 16:53:56 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UJ9T-0000lU-00; Mon, 5 Apr 1999 16:51:35 -0700 Received: from relay2.faa.gov [204.108.10.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UJ9R-0000lK-00; Mon, 5 Apr 1999 16:51:34 -0700 Received: from faa.gov ([192.168.254.2]) by relay2.faa.gov (Pro-8.9.3/Pro-8.9.3) with SMTP id TAA29193; Mon, 5 Apr 1999 19:45:58 -0400 (EDT) Received: from POP3 Client by faa.gov (ccMail Link to SMTP R8.20.00.25) id AA923355236; Mon, 05 Apr 1999 19:39:31 -0500 Message-Id: <9904059233.AA923355236@faa.gov> X-Mailer: ccMail Link to SMTP R8.20.00.25 Date: Mon, 05 Apr 1999 16:40:47 -0500 From: "Prof. Carlos B. Westphall" To: , , Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: IEEE LANOMS99 - Call for Papers MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --simple boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable *********** PLEASE=2C OBSERVE THE NEW DEADLINE MAY 06=2C 1999 ******= ******** **** I am sorry if you receive more than one copy of this e-mail *****= **** ***********************************************************************= **** LANOMS=B499 IEEE Latin American Network Operations and Management Symposium Rio de Janeiro - Brazil=2C December 03 - 04=2C 1999=2E =20 "NETWORK MANAGEMENT FOR THE NEW WORLD=22=20 =20 Call for Papers =20 =20 The First Latin American Network Operations and Management Symposium - = LANOMS=2C to be held in Rio de Janeiro on the turn of the millennium is= the result of the great success of the events in the area of=20 network management known as NOMS and APNOMS=2E NOMS (Network Operations= =20 and Management Symposium=29 was originally created ten years ago in=20 New Orleans=2C USA=2C and nowadays constitutes a worldwide event for th= e researches in the area of network management=2E Recently=2C the=20 Asia=2FPacific community promoted the APNOMS (Asia-Pacific=20 Network Operations and Management Symposium=29=2C which is an event mor= e=20 oriented to the research and development community in that continent=2E= =20 Within this context=2C we will promote the first LANOMS=20 =28http=3A=2F=2Fwww=2Elrg=2Eufsc=2Ebr=2F~lanoms99=29 in order to stimul= ate the=20 researches in Latin America=2E It is important to emphasize that this event will be held in the same hotel and two days before the = GLOBECOM=2E In the last few years=2C we have been witnessing an increasing demand o= n=20 topics associated with Network Management in national and international= =20 events=2C organized mainly in Brazil=2C Mexico=2C Chile=2C Argentina=2C= and Uruguay=2E=20 As a consequence=2C we observed in Latin America a solid necessity of a= =20 specific event where there might be room to debate the main issues invo= lving the=20 area of Network Management=2E For obvious reasons=2C the organization o= f=20 LANOMS will be tuned with NOMS and APNOMS to even stimulate the partici= pation=20 of the Latin American community in these events=2E As LANOMS derives fr= om NOMS=2C keeping its original characteristics=2C it will create a forum = which is more specific to the requirements of Latin America in the area= of Network Management involving telecommunication companies=2C=20 academic institutions=2C service providers and equipment vendors=2E Alt= hough organized in Latin America=2C LANOMS will be opened to participants=20 =28researchers=2C developers=2C investors=2C etc=29 from other continen= ts who are interested in having=2C or already have=2C research or commerci= al=20 liaisons in Latin America=2E The objectives of LANOMS include=2C but ar= e not limited to=3A * to satisfy an increasing necessity of organizing a specific = event on network management in Latin America in order to = divulge the researches currently developed=3B * to identify the problems and solutions specific to the area = of network management=3B * to make viable the solutions proposed by the international = community to Latin America and vice-versa=3B and=20 * to expose the potentialities of the Network Management area=3B= Submissions should be complete=2C full-length papers and should not exc= eed =20 12 pages=2E Electronic submission of papers is strongly encouraged=2E = Full=20 instructions for the electronic submissions will be available soon on t= he LANOMS web page=2E=20 Important Dates=3A Paper due=3A May 06=2C 1999 Notification=3A Aug=2E 06=2C 1999 Camera Ready=3A Sep=2E 06=2C 1999 Suggested Topics=3A + Artificial Intelligence Solutions for Network Management + Broadband Network Management Implementation + Business and Service Management + CORBA Support for Distributed Management + Distributed Network and Service Management + Enterprise Management + Experiences in Management Environments + Intelligent Agents + Interoperability and Platforms + Network Operation and Management Solutions for Latin America + Neural Networks Technologies + New Technologies and Methodologies + Proactive Management + Protocol Specifications + SONET=2FSDH=2FATM + Security Management + Telecommunication Policies + Traffic and Performance Management + TMN Technology + Web-Based Management=20 Committee Members --------- ------- General and TCP Chair=3A =20 Carlos Becker Westphall=2C Brazil=20 =20 TPC Co-Chairs=3A =20 Luiz Fernando Kormann=2C Brazil=20 Mirela Sechi Moretti Annoni Notare=2C Brazil=20 =20 Publication Chair=3A =20 Bernardo Goncalves Riso=2C Brazil=20 =20 Publicity Chair=3A =20 Juan Carlos Miguez=2C Uruguay=20 =20 Finance Chair=3A =20 Fernando Augusto da Silva Cruz=2C Brazil=20 Joao Bosco Mangueira Sobral=2C Brazil=20 =20 Local Arrangements Chair=3A =20 Michael Stanton=2C Brazil =20 =20 IEEE CNOM Officer=3A=20 Veli Sahin=2C USA=20 =20 International Liasions=3A=20 Africa=3A J=2E Roos=2C South Africa=20 Asia=3A J=2E Hong=2C Korea =20 Europe=3A E=2E Bagnasco=2C Italy =20 N=2E America=3A S=2E Aidarous=2C USA =20 Oceania=3A P=2E Ray=2C Australia =20 =20 Advisory Board=3A=20 B=2E Meandzijas=2C USA=20 D=2E Zuckermann=2C USA=20 M=2E Ejiri=2C Japan=20 M=2E Yoshida=2C Japan=20 R=2E Saracco=2C Italy=20 S=2E Goyal=2C USA=20 W=2E Zimmer=2C Germany=20 =20 Technical Program Committee=20 Adarsh Sethi (USA=29=20 Alan Mckinlay (UK=29=20 Alejandro Miralles (Chile=29 Behcet Sarikaya (Japan=29=20 Carlos de Lara (Mexico=29=20 Carlos E=2E Caicedo (Colombia=29=20 Eduard Pinnes (USA=29=20 Edmundo R=2E Madeira (Brazil=29 Elias Procopio Duarte Junior (Brazil=29=20 Gabriel Jakobson (USA=29=20 German Goldszmidt (USA=29=20 Guy Pujolle (France=29 =20 Heinz-Gerd Hegering (Germany=29=20 Joberto S=2E Barbosa Martins (Brazil=29=20 Jong-Tae Park (Korea=29=20 Jose Marcos Nogueira (Brazil=29=20 Jose Neuman de Souza (Brazil=29=20 Keith-Stuart von Mecklenburg (UK=29=20 Leonor W=2E Chaux (Colombia=29=20 Manu Malek (USA=29=20 Manoel C=2E Penna (Brazil=29 =20 Michael Bauer (Canada=29=20 Michele Sibilla (France=29=20 Nelson Fonseca (Brazil=29=20 Osvaldo Bianchi (Argentina=29=20 Paulo Gomide Cohn (Brazil=29=20 Raul Monge (Chile=29=20 Robert Weihmayer (USA=29=20 Roberto Vercelli (Italy=29 =20 Varoozh Harikian (Belgium=29=20 =20 This event is Technically Co-Sponsored by the IEEE ComSoc=2E Contact Address=3A Carlos Becker Westphall (LANOMS=B499 General Chair=29 Federal University of Santa Catarina - UFSC Technological Center - CTC Network and Management Laboratory - LRG P=2EO=2EBox 476=20 88040 970 Florianopolis - SC BRAZIL lanoms99=40lrg=2Eufsc=2Ebr =20 http=3A=2F=2Fwww=2Elrg=2Eufsc=2Ebr=2F~lanoms99 =20 = --simple boundary-- From rem-conf Tue Apr 06 08:51:58 1999 From rem-conf-request@es.net Tue Apr 06 08:51:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UXyW-0000K7-00; Tue, 6 Apr 1999 08:41:16 -0700 Received: from dmog10.bell.ca [198.235.69.18] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UXyV-0000Jm-00; Tue, 6 Apr 1999 08:41:15 -0700 Received: from notesmta.bell.ca ([142.112.113.9]) by dmog10.bell.ca with SMTP id LAA25002; Tue, 6 Apr 1999 11:39:35 -0400 (EDT) From: yvlepage@post.bell.ca Received: by notesmta.bell.ca(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 8525674B.00563E99 ; Tue, 6 Apr 1999 11:42:01 -0400 X-Lotus-FromDomain: BELLCANADA@NOTESMTA To: mbone@isi.edu, rem-conf@es.net Message-ID: <8525674B.00563D1A.00@notesmta.bell.ca> Date: Tue, 6 Apr 1999 11:39:02 -0400 Subject: Virtual MBone book Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi everyone, In 1996, Kevin Savetz, Neil Randall and myself, Yves Lepage have written a book titled "MBone: Multicasting Tomorrow's Internet". This book is now out of print and we've decided to web'ize it and make the content available to the MBone community. We're currently finalizing the web'ization of the book and what we've done so far can be accessed at http://www.savetz.com/mbone/ The whole content of the book will soon be on-line and this virtual book may become available on other web sites as well in the future. We hope that it can be useful to people in here. Particularly, the book is a decent user guide and could probably constitute an FAQ. It was written in the ole days when tunnelling was the preferred way of interconnecting multicast-enabled networks. However, the more recent tools such as SDR (as opposed to SD) and vic are covered. Have a good reading, Yves Lepage for Kevin Savetz Neil Randall Yves Lepage From rem-conf Tue Apr 06 09:38:44 1999 From rem-conf-request@es.net Tue Apr 06 09:38:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UYq1-0001jP-00; Tue, 6 Apr 1999 09:36:33 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UYq0-0001jF-00; Tue, 6 Apr 1999 09:36:32 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id JAA01556; Tue, 6 Apr 1999 09:36:31 -0700 (PDT) Message-Id: <3.0.3.32.19990406093631.00ae26c0@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 06 Apr 1999 09:36:31 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 4/7 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar An Architecture for a Global Internet Host Distance Estimation Service Wednesday, April 7, 1999, 1:00-2:30 p.m. 405 Soda Hall Please note the time frame of the seminar series has changed!! Sugih Jamin Electrical Engineering and Computer Sciences, U of Michigan There is an increasing need for Internet hosts to be able to quickly and efficiently learn the distance, in terms of metrics such as latency or bandwidth, between Internet hosts. For example, to select the nearest of multiple equal-content web servers. This talk explores technical issues related to the creation of a public infrastructure service to provide such information. In so doing, we suggests an architecture, called IDMaps, whereby Internet distance information is distributed over the Internet, using IP multicast groups, in the form of a virtual distance map. Systems listening to the groups can estimate the distance between any pair of IP addresses by running a spanning tree algorithm over the received distance map. We also presents the results of experiments that give preliminary evidence supporting the architecture. This work thus lays the initial foundation for future work in this new area. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Apr 06 10:37:50 1999 From rem-conf-request@es.net Tue Apr 06 10:37:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UZjE-0002yw-00; Tue, 6 Apr 1999 10:33:36 -0700 Received: from e2.clubs.yahoo.com [204.71.200.172] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UZjD-0002yj-00; Tue, 6 Apr 1999 10:33:35 -0700 Received: (from yahoo@localhost) by e2.clubs.yahoo.com (8.8.7/8.8.8) id KAA22790; Tue, 6 Apr 1999 10:32:34 -0700 (PDT) Date: Tue, 6 Apr 1999 10:32:34 -0700 (PDT) From: Yahoo! Clubs Message-Id: <199904061732.KAA22790@e2.clubs.yahoo.com> To: rem-conf@es.net Reply-To: ramiro_g@mailexcite.com Subject: You're invited! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello! You have been invited by elparto to join the Listed Yahoo! Club named "Internet Telephony". To become a member of this club, just go to the Web address below: http://edit.clubs.yahoo.com/config/sjg?.i=internettelephony&.a=i& You need to go to the address above to join the club, but you can take a look at the club by going to: http://clubs.yahoo.com/clubs/internettelephony You can learn more about elparto by looking at the Yahoo! Public Profile: http://profiles.yahoo.com/elparto A Yahoo! Club is a great way to bring friends, family or anyone you know together using the latest in Web technologies. Club members are able to take advantage of a club's private chat room, message boards and other features. You can also create your own free club focused on any interest, such as hobbies, families and industry associations. Clubs are either listed or unlisted. Listed clubs are available to the public while unlisted clubs are available exclusively to those who receive invitations. If you have no interest in joining this club, there is no need for you to do anything. You will not be enrolled as a member. Thanks, The Yahoo! Clubs team http://clubs.yahoo.com/ P.S. If you need some help on getting started, go to: http://help.yahoo.com/help/clubs/ From rem-conf Tue Apr 06 13:01:23 1999 From rem-conf-request@es.net Tue Apr 06 13:01:22 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Ubwm-0005CK-00; Tue, 6 Apr 1999 12:55:44 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Ubwl-0005CA-00; Tue, 6 Apr 1999 12:55:43 -0700 Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id MAA14362 for ; Tue, 6 Apr 1999 12:49:48 -0700 Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id ; Tue, 06 Apr 1999 12:49:42 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id MAA15892; Tue, 6 Apr 1999 12:49:37 -0700 MIME-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: References: Date: Tue, 6 Apr 1999 12:46:45 -0700 To: Stephen Casner From: Dave Singer Subject: Re: payload name and type for H263+ (RFC2429) Cc: cabo@tzi.org, rem-conf@es.net, kevin@apple.com Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 12:22 AM -0800 3/5/99, Stephen Casner wrote: >On Thu, 4 Mar 1999, Dave Singer wrote: >> RFC 2429 says that "Payload Type (PT): The Payload Type shall specify the >> H.263+ video payload format." Presumably somewhere the Mime name is >> defined for this. What is it? (Where is it?). I missed it. > >I have made another revision to both the RTP spec and the profile. >(See my next message on that topic.) In the profile, I have added >"H263-1998", which is the name suggested by Joerg or Carsten, I >believe. > >Also, please note that Philipp Hoschka has done a rough draft on the >MIME registration of names from the RTP profile. > -- Steve Was this the final call for the name? It's not in the IANA, draft-hoschka-rtp-mime-00.txt, or the RFC, so I want to be sure... David Singer Apple Computer/QuickTime From rem-conf Tue Apr 06 16:27:20 1999 From rem-conf-request@es.net Tue Apr 06 16:27:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UfCZ-0007ih-00; Tue, 6 Apr 1999 16:24:15 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UfCX-0007iW-00; Tue, 6 Apr 1999 16:24:13 -0700 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA04911; Tue, 6 Apr 1999 16:23:12 -0700 (PDT) Date: Tue, 6 Apr 1999 16:27:09 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Confirmation of AVT actions in Minnesota Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As listed in the minutes of the Minneapolis AVT working group meeting, we have the following actions from the meeting to confirm on the mailing list: 1. draft-mckay-qcelp-02.txt is a revision to the PureVoice (QCELP) payload format to address comments received on the previous version of the draft during working group last call. In particular, the specification of encryption has been removed. Since the working group last call actually began about two meetings ago, one additional week will be allowed for comment, and then the draft will be submitted for publication as a Proposed Standard. 2. At the meeting, it was agreed that working group last call should be issued for draft-ietf-avt-rtp-format-guidelines-01.txt, the guidelines for writers of RTP payload format specifications. If no comments requiring changes are received in the next two weeks, this draft will be submitted for publication as a Best Current Practice. 3. In the discussion of RTP multiplexing, a strawman plan for how to proceed was presented and received "rough consensus" of the AVT meeting attendees. The plan was that we should work on standardizing just one scheme, the current GeRM proposal. We will take GeRM as our starting point and try implementing it for the proposed scenarios. Then we can see whether there are any serious limitations that can't be fixed and would justify standardizing another solution. (Note that designers of specific applications may choose to implement their own multiplexing schemes that may or may not bear any resemblence to RTP, and there would not be a need for these schemes to be standardized by AVT.) 4. The following three drafts were accepted as AVT work items: - RTCP conformance testing (draft-ietf-avt-rtcptest-00.txt) - Loss-tolerant payload format for MPEG audio (draft-finlayson-rtp-mp3-00.txt) - DV format video payload format (draft-kobayashi-dv-video-00.txt) Since working group decisions must receive confirmation on the mailing list, this is the opportunity for those who could not attend (as well as those who did) to object. Silence is deemed confirmation. -- Steve From rem-conf Tue Apr 06 18:03:32 1999 From rem-conf-request@es.net Tue Apr 06 18:03:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UghP-0001PR-00; Tue, 6 Apr 1999 18:00:11 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UghN-0001Ns-00; Tue, 6 Apr 1999 18:00:09 -0700 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA06199; Tue, 6 Apr 1999 17:59:09 -0700 (PDT) Date: Tue, 6 Apr 1999 18:03:06 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Interim AVT/MPEG meeting on MPEG-4 over RTP Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In the evening between the two sessions of the Minneapolis AVT working group meeting, a conference call was held with the MPEG-4-on-IP ad-hoc group of the MPEG committee which was meeting the same week in Seoul. It was proposed then to have an interim meeting to discuss the topic of MPEG-4 payload format for RTP. That meeting has been set for Sunday, April 25, 9am - 5pm, at Columbia University in New York (the day before the Packet Video Workshop). Any interested AVT working group participants are invited to attend. Contact Andrea Basso for meeting details so that he can track the attendee list. -- Steve From rem-conf Tue Apr 06 18:47:49 1999 From rem-conf-request@es.net Tue Apr 06 18:47:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UhQC-0002oC-00; Tue, 6 Apr 1999 18:46:28 -0700 Received: from igate.nuera.com (exchangesvr.nuera.com) [204.216.240.98] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UhQA-0002nn-00; Tue, 6 Apr 1999 18:46:26 -0700 Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.1960.3) id <2FB96FMV>; Tue, 6 Apr 1999 18:50:57 -0700 Message-ID: From: "Fox, Mike" To: Stephen Casner Cc: rem-conf@es.net Subject: RE: Confirmation of AVT actions in Minnesota Date: Tue, 6 Apr 1999 18:50:57 -0700 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 What happened to the DTMF proposal? Mike Fox From rem-conf Tue Apr 06 19:16:19 1999 From rem-conf-request@es.net Tue Apr 06 19:16:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Uhr4-0003d0-00; Tue, 6 Apr 1999 19:14:14 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Uhr2-0003cj-00; Tue, 6 Apr 1999 19:14:12 -0700 Received: from casner-pc.cisco.com (casner-pc.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id TAA06862; Tue, 6 Apr 1999 19:13:10 -0700 (PDT) Date: Tue, 6 Apr 1999 19:17:08 -0700 (Pacific Daylight Time) From: Stephen Casner To: "Fox, Mike" cc: rem-conf@es.net Subject: RE: Confirmation of AVT actions in Minnesota In-Reply-To: Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mike Fox asked: > What happened to the DTMF proposal? Several people have asked about the status of the DTMF proposal. The status is that Henning Schulzrinne and Scott Petrack plan to merge their drafts into one, but they were unable to do so before the I-D submission deadline for the last IETF meeting nor by the time of the meeting. Hence it was not on the AVT agenda. I believe both intend to get this done "real soon now". In fact, Scott said he could "absolutely committ" to updating the draft within a month if Henning didn't, but I'm not sure when that month started. I think both Scott and Henning see this list, so your query should serve as a poke. To Scott and Henning: I have seen offers from others who would be glad to take on this merging task for you if you would like to relinquish it. -- Steve From rem-conf Wed Apr 07 00:17:36 1999 From rem-conf-request@es.net Wed Apr 07 00:17:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UmXf-0006PF-00; Wed, 7 Apr 1999 00:14:31 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UmXd-0006Oy-00; Wed, 7 Apr 1999 00:14:29 -0700 Received: from CASNER-ISDN1 ([171.70.119.74]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id AAA08507; Wed, 7 Apr 1999 00:12:36 -0700 (PDT) Date: Wed, 7 Apr 1999 00:12:34 -0700 (Pacific Daylight Time) From: Stephen Casner To: Dave Singer cc: cabo@tzi.org, rem-conf@es.net, kevin@apple.com Subject: Re: payload name and type for H263+ (RFC2429) In-Reply-To: Message-ID: X-X-Sender: casner@ursamajor.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave, > >I have made another revision to both the RTP spec and the profile. > >(See my next message on that topic.) In the profile, I have added > >"H263-1998", which is the name suggested by Joerg or Carsten, I > >believe. > Was this the final call for the name? I have not heard any objections. What do you think? Anyone else have comments? > It's not in the IANA, > draft-hoschka-rtp-mime-00.txt, or the RFC, so I want to be sure... Yes, the IANA list has not been updated, and draft-hoschka was being prepared at the same time as I was last updating the profile... We'll get there. -- Steve From rem-conf Wed Apr 07 02:33:12 1999 From rem-conf-request@es.net Wed Apr 07 02:33:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Uofw-0000Lf-00; Wed, 7 Apr 1999 02:31:12 -0700 Received: from nscolmar.colmar.uha.fr [194.167.108.34] by mail1.es.net with smtp (Exim 1.81 #2) id 10Uoe1-0000K5-00; Wed, 7 Apr 1999 02:30:10 -0700 Received: by nscolmar.colmar.uha.fr; (5.65v3.2/1.3/10May95) id AA27012; Wed, 7 Apr 1999 11:03:50 +0200 Received: from somewhere by smtpxd Message-Id: <3.0.5.32.19990407112031.007a0500@colmar.colmar.uha.fr> X-Sender: conf@colmar.colmar.uha.fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 07 Apr 1999 11:20:31 +0200 To: conf@colmar.colmar.uha.fr From: Conf ICATM99 Subject: ICATM99 - Preliminary Program Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please feel free to circulate this following preliminary program of ICATM99 to interested colleagues (see http://iutsun1.colmar.uha.fr/ICATM99.html for more information).=20 Accept our sincere apologies if you receive multiple copies. ------------------------------------------------------------------ TECHNICAL PROGRAM 08:00 - 18:00 Conference Registration Monday June 21 08:30 - 09:00 Opening Address=20 09:00 - 10:00 Tutorial Session 1 Chair: M. Lee Mobile and Wireless ATM Networks - Third Generation Systems (UMTS/IMT2000) G. Omiyar, GTE Telecom, Egypt 10:00 - 10:30 Coffee Break 10:30 - 11:30 Tutorial Session 2 Chair: S. Rao Rich VPNs: the Best win-win Deal between a Carrier and its Customers S. Ritzenthaler, Newbridge, France 11:30 - 12:30 Tutorial Session 3 Chair: J. Crowcroft Implementing Ipv6 over ATM M. Souissi, F. Dupont, B. Leroy, INRIA Rocquencourt, France 12:30 - 14:00 Lunch - Restaurant Universitaire 14:00 - 15:30 Wireless ATM 1 Chair: G.S. Kuo A Hybrid Data/Header Interleaving Strategy for Wireless ATM Networks S.T. Sheu, T.F. Sheu, TamKang University, China A Deadlock Model for a Multi-Service Medium access Protocol Employing Multi-Slot N-ARY Stack Algorithm (MSSTART) F. Cameron, M. Zukerman, University of Melbourne, Australia Optimal DLC Protocol Configuration for Realistic Broadband Fixed Wireless Access Networks based on ATM S. Mangold, Aachen University of Technology, Germany 14:00 - 15:30 Flow Control in ATM: ABR 1 Chair: P. Rolin Guaranteeing Fairness and Protection in ABR by Means of Fair Queuing L.A. Guijarro, J.R. Vidal, J.Martinez, University of Valencia, Spain Fluid Analysis of a TCP Connection over ABR, in Presence of Exogenous Flow J.L. Costeux, CNET, France Bidirectional ABR Mechanism P. Homan, J. Bester, University of Ljubljana, Slovenia 15:30 - 15:45 Coffee Break 15:45 - 17:15 Wireless ATM 2 Chair: G. Omidyar Routing Protocols for Wireless Ad hoc ATM Networks A. Hettich, A. Kadelka, H. Kukulies, Aachen University of Technology,= Germany Hand-Off and Synchronization Protocol for Supporting Multimedia Communications in an ATM based Wireless Network A. Leon, M. Esteve, J.C. Guerri, C. Palau, A. Pajares, Polytechnic University of Valencia, Spain A Flexible Signaling Protocol for Supporting Switched AAL Type 2 Connections in UMTS Terrestrial Radio Access Networks I.. Szabo, Ericsson, Hungary 15:45 - 17:15 Flow Control in ATM: ABR 2 Chair: G. Pujolle Evaluation of the Virtual Source/Virtual Destination-Technique for Available Bit Rate Traffic in ATM-Networks J. Baalmann, C. Cseh, University of Technology Aachen, Germany ABR Rate Control for Multimedia Traffic using Microeconomics E.W. Fulp, D.S. Reeves, North Carolina State University, USA Evaluation of the TCP Traffic over the ABR Service Targeted to Support Mass Storage Applications I. Mountzouris, G. Orphanos, A. Birbas, S. Koubias, G. Papadopoulos, University of Patras, Greece 17:15 - 17:30 Coffee Break 17:30 - 19:00 Management Chair: S. Rao Model-Based-Diagnosis for Fault Management in ATM Networks F. Krief, A. Osmani, Institut Galil=E9e, France A Model of Fault Messages for Maintenance of UNI/NNI Resources in HANbit ACE64 ATM Switching System G. Kwon, ETRI, Korea Dynamic Management of Routing Tables and Connection Re-routing in ATM= Networks S. Kumar, S.V. Raghavan, Indian Institute of Technology Madras, India 17:30 - 19:00 Multicast Chair: J.J. Pansiot Compound VC Mechanism for native Multicast in ATM Networks J. Mangues-Bafalluy, J. Domingo-Pascual, Polytechnic University of Catalunya, Spain IPv6 Multicasting over ATM Testbed J.S. Silva, N. Veiga, S. Duarte, F. Boavida, University of Coimbra, Portugal Design and Analysis of Multicast Delivery to Provide VCR Functionality in Video-on Demand Systems W. Poo, K.T. Lo, The Hong Kong Polytechnic University, Hong Kong ; J. Feng, City University of Hong Kong, Hong Kong Tuesday June 22 09:00 - 10:30 Real-Time Traffic Chair: M. Dickmann A Method for Accurate Time Synchronization through In-Service Monitoring in ATM Networks D. Vidal, University of the Balearic Islands, Spain Delay Jitter Guarantee for Real-Time Communications with ATM Network Z. Mammeri, University Paul Sabatier, France Hierarchical Vector Clock: Scalable Plausible Clock for Detecting Causality in Large Distributed Systems D.A. Khotimsky, Lucent Technologies, USA ; I.A. Zhuklinets, Mozhaysky Academy, Russia 09:00 - 10:30 IP over ATM 1 Chair: G. Girardi Shortcutting IP Flows over Large ATM Networks J. Schmitt, L. Wolf, M. Karsten, R. Steinmetz, Darmstadt University of Technology, Germany ; Y.O. Lorcy, C. Siebel, Deutsche Telekom, Germany Measurement-Based Simulation Model for TCP over ATM G. Seres, T. Elteto, A. Olah, Ericsson telecommunications, Hungary On the Efficiency of Packet telephony over IP and ATM M. Baldi, F. Risso, Polytechnic of Torino, Italy 10:30 - 11:00 Coffee Break 11:00 - 12:30 Traffic Control Chair: D. Kofman Networks Performance Based Connection Admission Control Model in ATM Networks: Immediate and Future Reservation Approaches M. Nour, University of Montreal, Canada ; A. Hafid University of Western Ontario, Canada ; M. Gendreau, University of Montreal, Canada Validating novel CAC algorithms on ATM testbeds J. Levendovszky, Z. Elek, C. Vegso, Technical University of Budapest,= Hungary The Design of an Object-Oriented Simulation Tool for Evaluating ATM Network Resource Control Scheme J. Soldatos, D. Vergados, E. Vayias, N. Mitrou, National Technical University of Athens, Greece 11:00 - 12:30 IP over ATM 2 Chair: F. Vanney A Framework for Testing IP QoS over ATM Networks: Implementation and Practical Experiences N. Kroth, L. Mark, J. Tiemann, GMD, Germany A Study on Advanced Asynchronous Transfer Mode for High-Speed Computer Communication Networks K. Toyoshima, K. Hayashi, NTT, Japan VTOA/VoIP/ISDN Telephony Gateway A.M. Grilo, P.M. Carvalho, L.M. Medeiros, M.S. Nunes, INESC, Portugal 12:30 - 14:00 Lunch - Restaurant Universitaire 14:00 - 15:30 Quality of Service Chair: A. Benslimane Efficient Buffer Management and Scheduling in a Combined IntServ and DiffServ Architecture: a Performance Study G. Mamais, M. Markaki, G. Politis, I.S. Venieris, National Technical University of Athens, Greece Interaction of RSVP with ATM for the Support of Shortcut QoS Virtual= Channels R. Cocca, S. Salsano, CoRiTeL, Italy ; M. Listanti, University of Rome,= Italy Interactive Services over HFC Networks M.I. Borges Ribeiro, F. Fontes, J. Bastos, J. Loureiro, Portugal Telecom, Portugal 14:00 - 15:30 IP over ATM 3 Chair: M. Stuttgen Analysis on IP Label Switching Technology in Future Broadband Internet G.S. Kuo, H.C. Cheng, National Central University, Taiwan Analysis of Internet Services in IP over ATM Networks J. Aracil, M. Izal, D. Morato, University of Navarra, Spain Simulation and Analysis of IP/ATM Switching and Routing M.Z. Santos, L.G. Kiatake, F. Meylan, S.T. Kofuji, University of Sao Pailo, Brazil ; J.P. Coutiat, LAAS-CNRS, France 15:30 - 15:45 Coffee Break 15:45 - 17:15 Scheduling Chair: R. Muraine Flow Service Order: A Computationally Inexpensive Packet Scheduling Algorithm to Guarantee QoS for Real-Time Traffic S.R. Kulkarni, Indian Institute of Technology, India A Feasible Scheduling Algorithm for Per-VC Queuing ATM Switches P. Zhou, W.W. Yang, Nortel Networks, Canada Digital Neural Cell Schedulers for ATM Switch S.M. Lee, J.H. Chung, Y.C. Kim, M.M. Lee, Dongshin University, Korea 15:45 - 17:15 User Applications Chair: M. Potts ATM-Based Infrastructure for Teleteaching at University A. Klein, F. Bodendorf, University of Erlangen-Nuremberg, Germany Desktop Videoconferencing Performance and Quality of Service Evaluation on an ATM-based Metropolitan Area Network: OASICE Case Study H. Tobiet, Clemessy, France ; P. Lorenz, University of Haute Alsace, France Connecting Heterogeneous Supercomputers in Broadband Networks E. Pless, F. Hommes, GMD, Germany 17:15 - 17:30 Coffee Break 17:30 - 19:00 Management and multiplexing Chair: Z. Mammeri A Management System Providing Real Distribution of Management Tasks with Time and Space Independence F. Fontes, Portugal Telecom, Portugal ; T. De Miguel, A. Azcorra, University of Madrid, Spain Implementing Inverse Multiplexing for ATM A. Pires, Mitel Corporation, Canada The Heap-Sort Based ATM Cells Spacer T. Ha-Duong, MET, France 17:30 - 19:00 Protocols and Routing Chair: P. Droz Minimum Equivalent Subspanner Algorithms for Topology Aggregation in ATM Networks W. Chiou Lee, Motorola, USA Shared-Medium Architecture for ATM Local Network M. Soto, S. Sallent, Polytechnic University of Catalonia, Spain Analysis of the Crankback Probability in a Hierarchical PNNI Network J.L. Rougier, D. Kofman, ENST, France ; A.R. Ragozini, University of Napoli, Italy ; A. Gravey, CNET, France 20:00 Gala Dinner - Restaurant Meistermann Wednesday June 23 09:00 - 10:30 Intelligent Networks Chair: P. Lorenz Design and Implementation of an Intelligent Peripheral for Broadband Multimedia Applications H. Brandt, P. Todorova, GMD, Germany A TINA-Based Platform for Service Deployment and Usage J. P.C. Verhoosel, Telematics Institute, The Netherlands ; H.J. Batteram, J.L. Bakker, Lucents Technologies, The Netherlands Performance of the fair Intelligent Congestion Control for TCP Applications over ATM Networks D.B. Hoang, Q. Yu, University of Sydney, Australia 09:00 - 10:30 ATM Switches 1 Chair: Z. Hulicki RCES: A Replication/Contention/Elimination Strategy for Replication Baseline ATM Switch Architectures S.T. Sheu, Y.R. Chuang, TamKang University, China Advanced Frame Recovery in Switched Connection Inverse Multiplexing for ATM F.M. Chiussi, D.A. Khotimsky, S. Krishnan, Lucent Technologies, USA Implementation of an ATM Switch for PSTN/N-ISDN Services X. Gong, P. Zhang, W. Wang, S. Cheng, university of Posts and Telecom, China 10:30 - 11:00 Coffee Break 11:00 - 12:30 Error Detection and Correction Chair: O. Charles Implementation of an Error Detection-Recovery System based on Multimedia Collaboration Works: EDRS E.N. Ko, Sung Kyun Kwan University, South Korea New Error Control Enhancing Technique for Wireless ATM Networks M.M. Al-Khatib, M. Bayoumi, USL, USA A Parallel Reed-Solomon Coding/Decoding Structure for an ADSL Modem with Increased Interleaving for ATM Applications S. Toptchiyski, D. Sofos, V. Stylianakis, University of Patras, Greece 11:00 - 12:30 ATM Switches 2 Chair: S. Ritzenthaler An Efficient Address Assignment Strategy for Shared Multibuffer ATM Switches P.G. Lee, W.C. Kang, Y.H. Choi, Hongik University, Korea Implementation of Bifurcated Buffering in Input Buffer Banyan ATM Switch I.D. Radusinovic, Z.R. Petrovic, M.Pejanovic-Djurisic, University of Montenegro, Yugoslavia An Approximate Analysis of a Shared Buffer ATM Switch using Input Process Aggregation Technique J.Kim, C.H. Jun, Pohang University of Science and Technology, Korea ; K.P. Jun, Electronics and Telecommunications Research Institute, Korea 12:30 - 14:00 Lunch - Restaurant Universitaire 14:00 - 16:00 Performance Chair: H. Tobiet Performance Evaluation of a RR Switch for ABR Service D.H. Kim, Y.Z. Cho, Kyungpook National University, Korea Performance Models for IP Switching J. Zheng, V.O.K. Li, University of Hong Kong, Hong Kong Inverse Multiplexing for ATM Operation, Applications and Performance Evaluation Issues M. Aguilar-Igartua, J. Garcia-Haro, M. Postigo-Boix, Polytechnic University of Catalonia, Spain Performance Evaluation of Packet Discard Schemes in ATM Switches in Heterogeneous Traffic Environment Z. Jing, L. Li, University of Electronic Science and Technology, China ; H. Sun, Center for Advanced Computing and Communications, China 14:00 - 16:00 Video over ATM Chair: J. Montiel Error Resilient Protocol Architecture for the MPEG-2 Video Transmission over ATM Networks P. Cuenca, A. Garrido, F. Quiles, University of Castilla-La Mancha, Spain ; L. Orozco-Barbosa, University of Ottawa, Canada De-Jittering in the transport of MPEG-4 and MPEG-2 Video over ATM K. Shuaib, T. Saadawi, M. Lee, City College of New York, USA, B. Basch, GTE Laboratories, USA Proactive Management of MPEG Traffic in ATM Networks using Time Sequenced RLS Filters T.S. Randhawa, British Columbia Group, Canada ; R.H.S. Hardy, Simon Fraser University, Canada Linear Codes for End to end Cell Loss Recovery in VBR Video Transmission over ATM Networks Z. Alkhalifa, V.S.S. Nair, Southern Methodist University, USA 16:00 Closing Session ICATM'99 Registration Form Please mail the complete Registration Form to : Pascal LORENZ / ICATM'99 IUT/GTR - 34 rue du Grillenbreit - 68008 Colmar, France Phone : 33 (0)3 89 20 23 66=A0=A0 Fax : 33 (0)3 89 20 23 59=A0=A0 Mobile:= 33 (0)6 03 65 80 42 Email : lorenz@colmar.uha.fr Title: _______ First Name: _____________ Last Name: ______________________= =20 Institution: ___________________________________________________________=20 Street Address: ________________________________________________________=20 City: __________ State: ____________ Zip: ___________ Country: ____________= =20 Phone: ____________________________ Fax: ______________________________=20 Email : ____________________________=20 Arrival Date :=A0=A0=A0=A0 ____ June 1999 at _____=20 Departure Date :=A0=A0 ____ June 1999 at _____=20 Conference Registration Fees:=20 The Full registration fees include: attendance to the Conference, coffee breaks, 3 lunches, the gala dinner and the preprints.=20 Academic rate:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 IEE, IEEE, SEE Member=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 2400 FF=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 _________ FF=20 (Membership # __________)=20 non member=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 2600 FF=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 __________ FF=20 Industry rate:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 4000 FF=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 __________ FF=20 Additional Conference Proceedings (FF 400):=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __________FF=20 Additional Gala Dinner (FF 300):=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __________FF=20 =A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Total French Francs ..............=A0=A0 _________=20 Payment of Fees:=20 __ By Foreign Check in French Francs to "Office du Tourisme de Colmar".=20 __ By Bank Transfer to: Caisse d'Epargne d'Alsace, Avenue de la R=E9publique= , 68000 Colmar - France. Bank code: 16705 - Counter code: 09017 - Account number: 04100568821 - Key: 23 - Account name: Office du Tourisme de Colmar - Transfer Swift : BFCE FR PP 317=20 __ By Credit Card:=20 =A0=A0=A0=A0 __ Mastercard=20 =A0=A0=A0=A0 __ Visa=20 =A0=A0=A0=A0 __ American Express=20 Card number: _________________________=20 Expiration date: _________=20 Signature:=20 =A0=20 From rem-conf Wed Apr 07 08:40:12 1999 From rem-conf-request@es.net Wed Apr 07 08:40:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UuO7-0003oM-00; Wed, 7 Apr 1999 08:37:11 -0700 Received: from gateway-gw.pictel.com (gateway.pictel.com) [140.242.1.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UuO6-0003oC-00; Wed, 7 Apr 1999 08:37:10 -0700 Received: from pictel.com (roadrunner [140.242.64.4]) by gateway.pictel.com (8.9.2/8.9.2) with SMTP id LAA10470; Wed, 7 Apr 1999 11:36:49 -0400 (EDT) Received: from python.pictel.com by pictel.com (4.1/SMI-4.1) id AA13192; Wed, 7 Apr 99 11:36:45 EDT Received: by python.pictel.com (5.x/SMI-SVR4) id AA13174; Wed, 7 Apr 1999 11:36:41 -0400 Date: Wed, 7 Apr 1999 11:36:41 -0400 From: garys@pictel.com (Gary Sullivan) Message-Id: <9904071536.AA13174@python.pictel.com> To: casner@cisco.com, singer@apple.com Subject: Re: payload name and type for H263+ (RFC2429) Cc: cabo@tzi.org, kevin@apple.com, rem-conf@es.net, stewe@cs.tu-berlin.de, trgardos@ideal.jf.intel.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Re: *) I have not heard any objections. What do you think? Anyone else have *) comments? "H263-1998" looks good to me. -Gary Sullivan (editor and rapporteur for H.263) *) From casner@cisco.com Wed Apr 7 03:17:49 1999 *) *) *) Dave, *) *) > >I have made another revision to both the RTP spec and the profile. *) > >(See my next message on that topic.) In the profile, I have added *) > >"H263-1998", which is the name suggested by Joerg or Carsten, I *) > >believe. *) *) > Was this the final call for the name? *) *) I have not heard any objections. What do you think? Anyone else have *) comments? *) *) > It's not in the IANA, *) > draft-hoschka-rtp-mime-00.txt, or the RFC, so I want to be sure... *) *) Yes, the IANA list has not been updated, and draft-hoschka was being *) prepared at the same time as I was last updating the profile... *) We'll get there. -- Steve From rem-conf Wed Apr 07 14:05:01 1999 From rem-conf-request@es.net Wed Apr 07 14:05:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10UzK6-0007Xw-00; Wed, 7 Apr 1999 13:53:22 -0700 Received: from caffeine.public.hq.nasa.gov [198.116.65.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 10UzK5-0007Xl-00; Wed, 7 Apr 1999 13:53:21 -0700 Received: from el (Ellery.it.hq.nasa.gov [131.182.119.58]) by caffeine.public.hq.nasa.gov (8.7.5/8.7.3) with SMTP id QAA09305; Wed, 7 Apr 1999 16:53:17 -0400 (EDT) Message-Id: <3.0.32.19990407164953.009179b0@mail.hq.nasa.gov> X-Sender: ecolema1@mail.hq.nasa.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 07 Apr 1999 16:49:55 -0400 To: mbone@ISI.EDU, rem-conf@es.net From: "Ellery D. Coleman" Subject: NASA Medical Discussion on the MBONE Cc: virginia@real.com, L.Lambrinos@cs.ucl.ac.uk, jhall@UU.NET, hoag@plains.NoDak.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list If you have a spare minute or 2, please tune in to the session listed below: Title: NASA Workplace Health Surveillance Video: 224.2.193.17:54898 Audio: 224.2.193.16:20724 Any comments on quality of reception will be greatly appreciated. This discussion is expected to run from 9:30am to 12:30pm EDT. thanks, o-> el ps. Instructions on how to participate can be found at the following url: https://extranet.hq.nasa.gov/multicast/ From rem-conf Thu Apr 08 08:19:50 1999 From rem-conf-request@es.net Thu Apr 08 08:19:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10VGUB-00074B-00; Thu, 8 Apr 1999 08:12:55 -0700 Received: from caffeine.public.hq.nasa.gov [198.116.65.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 10VGUA-000741-00; Thu, 8 Apr 1999 08:12:54 -0700 Received: from el (Ellery.it.hq.nasa.gov [131.182.119.58]) by caffeine.public.hq.nasa.gov (8.7.5/8.7.3) with SMTP id LAA03527; Thu, 8 Apr 1999 11:12:47 -0400 (EDT) Message-Id: <3.0.32.19990408110923.009fdaf0@mail.hq.nasa.gov> X-Sender: ecolema1@mail.hq.nasa.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 08 Apr 1999 11:09:28 -0400 To: mbone@ISI.EDU, rem-conf@es.net From: "Ellery D. Coleman" Subject: LIVE: NASA Medical Discussion on the MBONE Cc: virginia@real.com, L.Lambrinos@cs.ucl.ac.uk, jhall@UU.NET, hoag@plains.NoDak.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please tune in to the session listed below for a minute or two: Title: NASA Workplace Health Surveillance Video: 224.2.193.17:54898 Audio: 224.2.193.16:20724 Any comments on quality of reception will be greatly appreciated. This discussion is expected to run from 9:30am to 12:30pm EDT. thanks, o-> el ps. Instructions on how to participate can be found at the following url: https://extranet.hq.nasa.gov/multicast/ From rem-conf Thu Apr 08 09:35:20 1999 From rem-conf-request@es.net Thu Apr 08 09:35:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10VHhd-0000XT-00; Thu, 8 Apr 1999 09:30:53 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10VHhc-0000XH-00; Thu, 8 Apr 1999 09:30:52 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id JAA08645; Thu, 8 Apr 1999 09:30:50 -0700 (PDT) Message-Id: <3.0.3.32.19990408093048.00af4210@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 08 Apr 1999 09:30:48 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 4/14 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Coding and Transport of Scalable Video Wednesday April 14, 1999, 1:00-2:30 p.m. 405 Soda Hall Please note the time frame of the seminar series has changed!! Wai Tian Tan Elec. Eng. and Comp. Sci. U.C. Berkeley Scalable video compression is suitable for Internet transmissions due to its ability to effect flow control. Examples are source-based rate control for unicast and layered multicast. However, without proper error control, the resulting video may not be of acceptable quality. We will describe some of the unicast experiments we have done over the Internet using bandwidth scalable video compression to motivate the design of our scalable compression scheme with error resilience. We will describe the use of the compression scheme in a unicast setting and present experimental results including comparisons with a forward error correction scheme. Finally we will discuss the applicability of the scheme for multicast transmissions. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Fri Apr 09 17:23:21 1999 From rem-conf-request@es.net Fri Apr 09 17:23:20 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10VlOM-0005LC-00; Fri, 9 Apr 1999 17:12:58 -0700 Received: from ppp19549.on.bellglobal.com (mail.mia.machine) [206.172.225.221] by mail1.es.net with smtp (Exim 1.81 #2) id 10VlOI-0005L2-00; Fri, 9 Apr 1999 17:12:56 -0700 From: Subject: HUMAN GROWTH HORMONES Date: Sun, 18 Apr 1999 06:58:57 Message-Id: Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Human Growth Hormone Available Now Without A Prescription Biggest Medical Breakthrough in Fat Loss & Anti-Aging in the 20th Century Order now and receive a "FREE GIFT" 1-800-704-4526 Now, for the first time ever, Human Growth Hormone is available without a prescription! Doctors have known for years that HGH : Decreases in;body fat, wrinkling, cholesterol, insomnia. Increases in;Physical strength, muscle mass, energy level, sexual function, mental alertness. Feelings of well being Stimulates youthful skin and hair appearance. Improves neurological function. Rejuvenates cell and organ tissue. HGH is now available to you in a SAFE, ALL NATURAL ORGANIC FORMULA, with no side effects when taken in a recommended dosage. HGH is a naturally occuring substance secreted by the pituitary gland, as our bodies age the pituitary's production of Human Growth Hormone decreases. The production of HGH helps slow down, and in some cases, even reverse the aging process. Over 1,000 doctors that atteneded the Anti-Aging conference in December agreed that HGH is one of the "most exciting advancements in reversing the disease of aging," since the introduction of DHEA. HGH has been used in Europe and the United States for approximately 15 years with amazing results. It has previously been available by injection only, and since injections by doctors cost between $5,000.00 and $20,000.00 a year, only the wealthy were able to afford these treatments. Now everyone can afford and receive the benefits of HGH. Now it is available for less than $100.00 per month in a handy application that you spray under your tongue, for instant absorption and FAST ACTING RESULTS!!! If you are interested in improving your quality of life, and your overall feeling of well being, then call 1-800-955-5553 to order your supply of HGH. Call within 24 hours of receiving this special offer and "get a FREE gift" from ADVANCED LABS. IF YOU CANNOT GET THROUGH TO OUR 800 NUMBER TRY THE FOLLOWING: to be removed email shasta@eastmail.com From rem-conf Sun Apr 11 18:13:56 1999 From rem-conf-request@es.net Sun Apr 11 18:13:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10WV7T-0006ul-00; Sun, 11 Apr 1999 18:02:35 -0700 Received: from aohakobe.ipc.chiba-u.ac.jp [133.82.241.137] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10WV7S-0006ub-00; Sun, 11 Apr 1999 18:02:34 -0700 Received: from aohakobe.ipc.chiba-u.ac.jp (yozo@localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.9.3/8.9.3) with ESMTP id KAA08137 for ; Mon, 12 Apr 1999 10:02:31 +0900 (JST) Message-Id: <199904120102.KAA08137@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: sdr problem? Date: Mon, 12 Apr 1999 10:02:30 +0900 From: Yozo Toda X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list hi. looks like sdr has some problem for cache file handling. anyone comment please? I'm joining sdr-monitor effort, sdr.tcl contains some code to let sdr write session information to the disk ("cache files") and send them by e-mail periodically(now the code is v4.0). as sdr's running, I observe the available disk space is getting smaller. there's no garbage seen, but when I quit sdr the value "avail" of the output of df command increases. I suppose sdr is holding (or forgetting to close) cache files after unlinking those files. is my supposition true? (sorry but I don't yet examine the source code...) -- yozo. From rem-conf Mon Apr 12 07:03:58 1999 From rem-conf-request@es.net Mon Apr 12 07:03:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10WhCL-00053s-00; Mon, 12 Apr 1999 06:56:25 -0700 Received: from ckgppxy1.att.com (ckgppxy1.proxy.att.com) [12.20.58.148] by mail1.es.net with esmtp (Exim 1.81 #2) id 10WhCK-00052s-00; Mon, 12 Apr 1999 06:56:24 -0700 Received: from flf960r1.ems.att.com ([135.71.244.37]) by ckgppxy1.proxy.att.com (AT&T IPNS/MS-2.2) with ESMTP id JAA12387; Mon, 12 Apr 1999 09:54:10 -0400 (EDT) Received: from njb140bh2.ems.att.com by flf960r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA06881; Mon, 12 Apr 1999 09:51:38 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2232.9) id <245B2CLC>; Mon, 12 Apr 1999 09:53:34 -0400 Message-ID: <1B08859602C8D211B66F0000C0769CFA09AB39@NJC240PO03> From: "Huebner, Frank, ALSVC" To: ac@enci.ucalgary.ca, achille@elet.polimi.it, activenets_all@ittc.ukansas.edu, andj@pact.srf.ac.uk, apc@eee.nthu.edu.tw, apclarke@usa.net, are.magnus.bruaset@si.sintef.na, arpanet-bboard@mc.lcs.mit.edu, atkinson@ucsd.edu, B.Marchent@fujitsu.co.uk, beadle@elec.uow.edu.au, Bharat.Patel@telematics.com, bmerriman@fusion.ucsd.edu, bmunro@agile.com, bob@boulderlabs.com, bparks@wuecona.wustl.edu, buford@cs.uml.edu, c.langreiter@tirol.com, cabernet-events@ncl.ac.uk, canning@cs.uml.edu, Carl.McCrosky@USask.CA, cell-relay@cell.onecall.net, chkoo@daisy.kwangwoon.ac.kr, cif@injector.ca.sandia.gov, claes@math.chalmers.se, claudio@dial.eunet.ch, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.a, cplus.guide@miningco.com, cssamuel@cphkvx.cphk.hk, D.D.Kouvatsos@comp.brad.ac.uk, D.J.Parish@lboro.ac.uk, dama@dist.unige.it, dancey@isomedia.com, davidc@davidc.com, dbword@cs.wisc.edu, dik_kalluri@uml.edu, dittmer@capital.net, dkamil@zd.com, ego@iis.nsk.su, elsa@econ.berkeley.edu, emmpdl@aaem.amc.anl.gov, end2end-interest@isi.edu, enternet@bbn.com, erahmmm@era-t.ericsson.se, erol@ee.duke.edu, feedback@techweb.com, FI51@vmxa.fz.telekom.de, flr@seiv10.rpi.ses.alcatel.es, fokus-users@fokus.gmd.de, fotios@vergina.eng.auth.gr, fransp@eos.cs.kun.nl, fred@langa.com, f-troup@codex.cis.upenn.edu, Gerry.Miles@telematics.com, gk@sics.se, gkonst@ektor.ntua.gr, gli@metal.chpc.ict.ac.cn, gmayor@pollux.usc.edu, gmyk@ektor.ntua.gr, grieblm@inforamp.net, g-troup@ccrc.wustl.edu, gus@bourg.net, habreu@bellsouth.net, hanoch@rutcor.rutgers.edu, hessa@acf4.nyu.edu, hipparch@sophia.inria.fr, hleitold@iaik.tu-graz.ac.at, hslee@nms.kyunghee.ac.kr, httpd@ncsa.uiuc.edu, I.M.MacPhee@durham.ac.uk, ieee.announce@bellcore.com, ieeetcpc@ccvm.sunysb.edu, ioannis@sce.carleton.ca, isi.mitrani@ncl.ac.uk, itc@attrh1.attrh.att.com, itrac@itrac.bourg.net, J.E.Mellor@durham.ac.uk, j.w.parker@bnr.co.uk, jay_weitzen@uml.edu, jekon@sunrise.pg.gda.pl, jem@sunsite.unc.edu, jesper@newton.mli.kvl.dk, jgobat@ucsd.edu, Jiang.Shengming@prism.uvsq.fr, jiann@newton.tuns.ca, jmsmith@ecs.umass.edu, johan@tts.lth.se, John.Kroeze@cs.kun.nl, John.Meyer@italtel.it, johnecarter@mindspring.com, jomah@cs.bris.ac.uk, jou@mcnc.org, jpearce@dcs.rhbnc.ac.uk, jraynard@freebsd.org, jwmark@bbcr.waterloo.edu, kapoor_v@motsat.sat.mot.com, kavid@telecom.ntua.gr, Kavitha_Chandra@uml.edu, kb7uzn@ida.net, kim@cs.uml.edu, kim@trillium.com, kl@lci.rug.ac.be, kofman@res.enst.fr, kohlen@etna.int-evry.fr, korez@res.enst.fr, kosberg@delab.sintef.no, koubias@ee.upatras.gr, koukias@wcl.ee.upatras.gr, kuehn@nvdv.e-technik.uni-stuttgart.dbp.de, kurose@cs.umass.edu, Kyamakya.Kyandoghere@FernUni-Hagen.de, lampe@math.tu-dresden.de, langford@cte.acu.edu, laws@stats.ox.ac.uk, leboudec@di.epfl.ch, Leila.Kloul@prism.uvsq.fr, levendov@hit.bme.hu, Lewis@stp.dias.ie, lmurphy@eng.auburn.edu, lobejko_@cc.wil.waw.pl, locigno@polito.it, lpa@log.on.ca, M.Merabti@livjm.ac.uk, macfadrn@boat.bt.com, machy@ix.netcom.com, maja.matijasevic@etf.hr, mal@qnx.com, marketing@trillium.co, marvin@mail.microserve.net, mary_bradburne@kvo.com, marzo@ei.udg.es, mascolo@poliba.it, medoe@essex.ac.uk, mellia@polito.it, mfc-mlorenz@visionx.com, Michael_Fiddy@uml.edu, michael_moeller@zd.com, miklos@ttt-atm.ttt.bme.hu, mitrou@ektor.ntua.gr, mlee@e0sun3.ccl.itri.org.tw, m-logo@wcl.ee.upatras.gr, mobile-ip@tadpole.com, moessenboeck@ssw.uni-linz.ac.at, mourad@scs.leeds.ac.uk, mst@amc-hln.com, multicomm@cc.bellcore.com, munafo@polito.it, muppala@cs.ust.hk, murphyj@eeng.dcu.ie, mustildp@boat.bt.com, N.Linge@eee.salford.ac.uk, naudts@uia.ua.ac.be, Nihal.Pekergin@prism.uvsq.fr, nilsson@eceyv.ncsu.edu, noconnell@stats.tcd.ie, olivier@smartcodesoft.com, osimcast@bbn.com, owner-tccc@majordomo.ieee.org, P.Jones@ee.surrey.ac.uk, Paglino@ilt9h23.settimo.italtel.it, pancha@ee.upenn.edu, pascua@tid.es, paul@math.nccu.edu.tw, pechiar@iie.edu.uy, Pekergin@lipn.univ-paris13.fr, performance@haven.epm.ornl.gov, Philip.Mars@durham.ac.uk, philippe.schweizer@pcm.bosch.de, pironneau@ann.jussieu.fr, pjbk@cee.hw.ac.uk, pka@itm.hk-r.se, Pravin.K.Johri@att.com, prof@gauss.wis.kuleuven.ac.be, prudhomm@ann.jussieu.fr, Q.Li@leeds.ac.uk, qli@cs.ucl.ac.uk, raif_onvural@alliedtelesyn.com, raschid@informatik.rwth-aachen.de, ravet@seua.am, rem-conf@es.net, reres@laas.fr, risingsun@msn.com, rnelson@watson.ibm.com, roitzsch@zib-berlin.de, Ross_Holmstrom@uml.edu, rvissers@voyager.net, S.Murphy@teltec.dcu.ie, sanjay@buckaroo.ho.att.com, shd@earthling.net, sigcomm-members@acm.org, sigmedia@bellcore.com, sigmetrics-bb@haven.epm.ornl.gov, simsuz@turing.utoronto.ca, SKKong@aol.com, skulski@nsrl.rochester.edu, sslaven@watson.ibm.com, stefan.wils@zorro.ruca.ua.ac.be, steve@nickel.laurentian.ca, stu@cs.uml.edu, support@tmt.com, sveo@itm.hk-r.se, T.Ors@ee.surrey.ac.uk, tap@ws7u.com, tccc@ieee.org, tcgn@ieee.org, tjp@dmu.ac.uk, ug@ica3.uni-stuttgart.de, ulfk@tts.lu.se, vfn@cs.utwente.nl, w3@unipress.com, wamckee@msn.com, wash@lambic.cfg.cornell.edu, wbmaster@psti.com, webmaster@ch.engr.ucdavis.edu, webmaster@planet-source-code.com, webmaster@spinweb.net, webmaster@streamsoft.com, webmasters@spinweb.net, werner@mosaic.co.za, woltman@magicnet.net, wviehmann@compuserve.com, www@astro.cf.ac.uk, xhafer@orion.eee.kcl.ac.uk, xiaowen@buckaroo.ho.att.com, xtp-relay@cs.concordia.ca, yakov@buckaroo.ho.att.com, ylevy@att.com, yodamon@aol.com, z.mihretu@statistics.bbk.ac.uk, Zhen.Liu@sophia.inria.fr Subject: IEEE LCN '99 Date: Mon, 12 Apr 1999 09:53:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ********** CALL FOR PAPERS ********** IEEE LCN '99 The 24th Annual Conference on Local Computer Networks "The Conference on Leading Edge and Practical Computer Networking" Lowell/Boston, Massachusetts October 17-20, 1999 Sponsored by IEEE Computer Society Technical Committee on Computer Communications Hosted by The University of Massachusetts, Lowell 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 researchers, users, and product developers. Sessions are being organized on: Internetworking Internet/Intranet Anything Over IP PCS/Wireless Networks/Mobile IP Performance Analysis - Modeling and Simulation - Tests and Measurements Network Management Network/Protocol Design Networking Issues for Smart Spaces High Speed Networks Real-Time Networks Active Networks Storage Area Networks ATM/Gigabit Ethernet Cable Modems/xDSL Virtual Private Networks Security/Privacy/Authentication Routing/Switching Multimedia Multicast Algorithms Quality of Service/Congestion Control Always On, Always Connected Emerging User Interfaces VLSI Impact on How to Build NWs Blue Tooth Networking to/at Home & Office Networking in the New Millennium Information for Authors: LCN '99 is soliciting both full and short papers for presentation at the conference. All submitted papers must be written in English, submitted electronically in PostScript format (alternatively, five hardcopies must be submitted to the address given below), and will be refereed by at least three reviewers. Full papers should present novel perspectives on computer networking within the scope of the conference sessions listed above. Full papers should present completed work, are expected to be of highest quality, and may be up to 10 camera-ready pages in length. Short papers are an opportunity to present preliminary or interim results prior to publication as a full paper and are limited to 2 camera-ready pages in length. Authors with accepted full (short) papers will give 20 (10) minute presentations at the conference. Both full and short papers will be published in the conference proceedings. There will be two categories of best paper award at LCN '99: the best overall paper and the best student paper. All papers must include title, complete contact information (Address, Phone, Fax, and E-Mail) for all authors, abstract, and keywords on the cover page. Manuscript submission instructions can be found at http://www.hill.com/lcn/lcn24submissions.html. Send papers to: Dr. Frank Huebner-Szabo de Bucs AT&T Labs, Room D5-3C18 200 Laurel Avenue Middletown, NJ 07748 U.S.A. E-mail: fhuebner@att.com Phone: +1 732-420-3718 Fax: +1 732-368-1919 Important dates: Submission: April 23, 1999 Acceptance: June 30, 1999 Camera Copy: August 13, 1999 For more information, please consult the LCN Web page at: http://www.hill.com/lcn From rem-conf Mon Apr 12 17:23:48 1999 From rem-conf-request@es.net Mon Apr 12 17:23:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Wqrb-0002PY-00; Mon, 12 Apr 1999 17:15:39 -0700 Received: from edtnps05.telusplanet.net [198.161.157.105] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Wqra-0002PK-00; Mon, 12 Apr 1999 17:15:38 -0700 Received: from clgrtnt4-port-219.agt.net ([161.184.49.219]:2269 "HELO art") by edtnps05.telusplanet.net with SMTP id <537722-18106>; Mon, 12 Apr 1999 18:14:50 -0600 From: dima@telusplanet.net To: dima@telusplanet.net Date: Mon, 12 Apr 1999 18:09:47 -0600 X-Distribution: Bulk MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Subject: SEE YOU AT NAB Priority: normal Message-Id: <19990413001459Z537722-18106+52@edtnps05.telusplanet.net> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list SPARK INTERACTIVE CORPORATION IN CO-OPERATION WITH WAMNET CORDIALLY INVITES YOU TO VIST WITH US AT NAB. WE WILL BE OUTSIDE THE LVCC IN THE BIG PURPLE WAMVAN. COMES SEE WHAT WE HAVE TO OFFER YOU IN REGARDS TO CONTENT AGGREGATION AND DIGITAL DELIVERY. BILL DEVER PRESIDENT SPARK INTERACTIVE CORPORATION dima@telusplanet.net SPARK INTERACTIVE CORPORATION Introduction: We are on the horizon of a digital revolution. Exciting new technologies are changing the way we work and play, including how we play games, shop, learn, do banking, listen to music, and watch our favorite movies. Imagine how joining this coming revolution will enhance all the entertainment you already enjoy. Imagine movies with interactive features, sharper pictures and enhanced sound. Imagine music with high quality, crystal-clear sound. Imagine instant access to thousands of games and motion pictures with full interactivity. Imagine watching the newest video release, or your favorite film classic, anytime of the day or night, exactly when you want to watch it. Now imagine this: a company with the facilities, film library, technical and business expertise to make it happen. SPARK INTERACTIVE makes =93being digital=94 a reality. The digital encoding of audio and video products, and the resulting spin-off of the Digital Versatile Disk (DVD) and Video on Demand (VOD) are the culmination of 15 years of development. SPARK INTERACTIVE has fostered a core of expertise that has made it a leader in bringing these new digital format entertainment products to the consumer. SPARK INTERACTIVE has combined the hardware, films, corporate alliances and management expertise launching it into a commanding position in the digital entertainment industry. SPARK INTERACTIVE is dedicated to providing its customers with all of their digital content and integration needs. Company Profile: SPARK INTERACTIVE (the =93Company=94) is currently licensing a film library in excess of 12,700 feature length motion pictures, which cover all genres. SPARK INTERACTIVE has the facilities to encode audio and video formats into digital format entertainment products. SPARK INTERACTIVE has the expertise to produce quality authoring, layout and interactive design. SPARK INTERACTIVE also has the know-how to assemble production studios for development of local content. SPARK INTERACTIVE has a mandate to constantly be developing new products and services to meet the demands of this growing industry. The mission of the Company is to focus on the distribution and aggregation of digitally encoded content for the interactive home and business marketplace, and to dedicate itself to eliminating the inconsistencies and complexities of acquiring and distributing interactive media. Its purpose is to provide the end user a total content package in a =93one-stop=94 solution which will satisfy the needs of his or her customer base. Company Products: SPARK INTERACTIVE offers products and services in the following areas: (1) licensing of digital encoded media, audio, video and games, (2) digitization and, (3) Integration of digital media solutions. SPARK INTERACTIVE sub-licenses and distributes the 12,700 movies titles, both in VHS and digital format through alliances with strategic partners in over 25 countries. The long relationship with all film studios can provide customers with all their Direct Broadcast Satellite (DBS), VOD and Cable film needs. SPARK INTERACTIVE also has access to 500 video games and a library of over 12,000,000 music titles. SPARK INTERACTIVE can provide the following types of content: Hollywood blockbusters, thousands independent and to classic foreign films, music, interactive gaming, distance learning and educational videos and e-commerce. SPARK INTERACTIVE performs the service of digitizing audio and video products both for external clients and its proprietary film library. Conversion of the material to the MPEG-2 format allows for it to be used in a number of applications the most prominent of which is DVD. Together with compression (space savings) the digitization of audio and video product facilitates enhancements to both sound and picture quality and allows for the addition of interactive elements. These interactive elements usually include instant access to particular scenes in a motion picture, as well as user-prompted informati-on such as biographies on the actors. The scope of these elements is unlimited. SPARK INTERACTIVE provides complete digital solutions for companies wanting to use digital compression technology to its fullest. The most common application of this product is VOD. SPARK INTERACTIVE provides VOD on various scales from a cruise ship to the classroom, from closed circuit local area networks to mass marketed cable networks, from digital content licensing to the design of live broadcast VOD production studios. VOD has evolved out of the Pay-Per-View service that many cable companies currently offer, VOD has shifted the control of the product being viewed and the time of viewing from the cable company to the consumer. Now, through a set-top-box such as a cable modem placed in the home, consumers can select from hundreds of movies and view them immediately with VCR functionality, all at a cost comparable to renting a video. And they get even more, digital-quality picture and sound, free previews, the assurance their selection is always available, and the convenience of watching their favorite programming without rewind charges, late return fees or trips to the video store. Conclusion: As the world=92s consumers demand more product to fill new outlets for entertainment created by emerging technologies, producers everywhere are taking position to supply the needs of the exploding information/entertainment market. SPARK INTERACTIVE knows that the development and introduction of the information appliance (i.e. a VOD set-top-box) into the home will create a global demand for digital information and entertainment products. Currently the world market for entertainment products is $600 billion, and SPARK INTERACTIVE feels that with this new ease of access that this figure will rise exponentially. SPARK INTERACTIVE is poised for the arising opportunities in the digital revolution. SEE YOU AT NAB 99 From rem-conf Mon Apr 12 17:28:18 1999 From rem-conf-request@es.net Mon Apr 12 17:28:17 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Wr1b-0002ZB-00; Mon, 12 Apr 1999 17:25:59 -0700 Received: from edtnps05.telusplanet.net [198.161.157.105] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Wr1a-0002Z1-00; Mon, 12 Apr 1999 17:25:58 -0700 Received: from clgrtnt4-port-219.agt.net ([161.184.49.219]:2316 "HELO art") by edtnps05.telusplanet.net with SMTP id <539131-18099>; Mon, 12 Apr 1999 18:25:13 -0600 From: dima@telusplanet.net To: dima@telusplanet.net Date: Mon, 12 Apr 1999 18:19:41 -0600 X-Distribution: Bulk MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Subject: SEE YOU AT NAB Priority: normal Message-Id: <19990413002521Z539131-18099+64@edtnps05.telusplanet.net> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list SPARK INTERACTIVE CORPORATION IN CO-OPERATION WITH WAMNET CORDIALLY INVITES YOU TO VIST WITH US AT NAB. WE WILL BE OUTSIDE THE LVCC IN THE BIG PURPLE WAMVAN. COMES SEE WHAT WE HAVE TO OFFER YOU IN REGARDS TO CONTENT AGGREGATION AND DIGITAL DELIVERY. BILL DEVER PRESIDENT SPARK INTERACTIVE CORPORATION dima@telusplanet.net SPARK INTERACTIVE CORPORATION Introduction: We are on the horizon of a digital revolution. Exciting new technologies are changing the way we work and play, including how we play games, shop, learn, do banking, listen to music, and watch our favorite movies. Imagine how joining this coming revolution will enhance all the entertainment you already enjoy. Imagine movies with interactive features, sharper pictures and enhanced sound. Imagine music with high quality, crystal-clear sound. Imagine instant access to thousands of games and motion pictures with full interactivity. Imagine watching the newest video release, or your favorite film classic, anytime of the day or night, exactly when you want to watch it. Now imagine this: a company with the facilities, film library, technical and business expertise to make it happen. SPARK INTERACTIVE makes =93being digital=94 a reality. The digital encoding of audio and video products, and the resulting spin-off of the Digital Versatile Disk (DVD) and Video on Demand (VOD) are the culmination of 15 years of development. SPARK INTERACTIVE has fostered a core of expertise that has made it a leader in bringing these new digital format entertainment products to the consumer. SPARK INTERACTIVE has combined the hardware, films, corporate alliances and management expertise launching it into a commanding position in the digital entertainment industry. SPARK INTERACTIVE is dedicated to providing its customers with all of their digital content and integration needs. Company Profile: SPARK INTERACTIVE (the =93Company=94) is currently licensing a film library in excess of 12,700 feature length motion pictures, which cover all genres. SPARK INTERACTIVE has the facilities to encode audio and video formats into digital format entertainment products. SPARK INTERACTIVE has the expertise to produce quality authoring, layout and interactive design. SPARK INTERACTIVE also has the know-how to assemble production studios for development of local content. SPARK INTERACTIVE has a mandate to constantly be developing new products and services to meet the demands of this growing industry. The mission of the Company is to focus on the distribution and aggregation of digitally encoded content for the interactive home and business marketplace, and to dedicate itself to eliminating the inconsistencies and complexities of acquiring and distributing interactive media. Its purpose is to provide the end user a total content package in a =93one-stop=94 solution which will satisfy the needs of his or her customer base. Company Products: SPARK INTERACTIVE offers products and services in the following areas: (1) licensing of digital encoded media, audio, video and games, (2) digitization and, (3) Integration of digital media solutions. SPARK INTERACTIVE sub-licenses and distributes the 12,700 movies titles, both in VHS and digital format through alliances with strategic partners in over 25 countries. The long relationship with all film studios can provide customers with all their Direct Broadcast Satellite (DBS), VOD and Cable film needs. SPARK INTERACTIVE also has access to 500 video games and a library of over 12,000,000 music titles. SPARK INTERACTIVE can provide the following types of content: Hollywood blockbusters, thousands independent and to classic foreign films, music, interactive gaming, distance learning and educational videos and e-commerce. SPARK INTERACTIVE performs the service of digitizing audio and video products both for external clients and its proprietary film library. Conversion of the material to the MPEG-2 format allows for it to be used in a number of applications the most prominent of which is DVD. Together with compression (space savings) the digitization of audio and video product facilitates enhancements to both sound and picture quality and allows for the addition of interactive elements. These interactive elements usually include instant access to particular scenes in a motion picture, as well as user-prompted informati-on such as biographies on the actors. The scope of these elements is unlimited. SPARK INTERACTIVE provides complete digital solutions for companies wanting to use digital compression technology to its fullest. The most common application of this product is VOD. SPARK INTERACTIVE provides VOD on various scales from a cruise ship to the classroom, from closed circuit local area networks to mass marketed cable networks, from digital content licensing to the design of live broadcast VOD production studios. VOD has evolved out of the Pay-Per-View service that many cable companies currently offer, VOD has shifted the control of the product being viewed and the time of viewing from the cable company to the consumer. Now, through a set-top-box such as a cable modem placed in the home, consumers can select from hundreds of movies and view them immediately with VCR functionality, all at a cost comparable to renting a video. And they get even more, digital-quality picture and sound, free previews, the assurance their selection is always available, and the convenience of watching their favorite programming without rewind charges, late return fees or trips to the video store. Conclusion: As the world=92s consumers demand more product to fill new outlets for entertainment created by emerging technologies, producers everywhere are taking position to supply the needs of the exploding information/entertainment market. SPARK INTERACTIVE knows that the development and introduction of the information appliance (i.e. a VOD set-top-box) into the home will create a global demand for digital information and entertainment products. Currently the world market for entertainment products is $600 billion, and SPARK INTERACTIVE feels that with this new ease of access that this figure will rise exponentially. SPARK INTERACTIVE is poised for the arising opportunities in the digital revolution. SEE YOU AT NAB 99 From rem-conf Mon Apr 12 22:15:13 1999 From rem-conf-request@es.net Mon Apr 12 22:15:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10WvQQ-0005NI-00; Mon, 12 Apr 1999 22:07:54 -0700 Received: from 98ce6bc0.ipt.aol.com (desktopserver98) [152.206.107.192] by mail1.es.net with smtp (Exim 1.81 #2) id 10WvQM-0005N3-00; Mon, 12 Apr 1999 22:07:52 -0700 From: Joe Scamporino To: Message-Id: <419.436262.92493634herbsway@aol.com> Subject: Re:Vitamins, Minerals & Herbs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Mon, 12 Apr 1999 22:07:52 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Why pay retail. When you can purchase direct and save up to 50%. Becomer a distributor and save $$$$$$$$$$$$!!!!! I'll show you how. Herbsway@aol.com From rem-conf Tue Apr 13 08:10:18 1999 From rem-conf-request@es.net Tue Apr 13 08:10:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10X4is-0001w9-00; Tue, 13 Apr 1999 08:03:34 -0700 Received: from mail-green.research.att.com [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 10X4ir-0001vz-00; Tue, 13 Apr 1999 08:03:33 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 098C51E015; Tue, 13 Apr 1999 11:03:31 -0400 (EDT) Received: from pcbasso.research.att.com (pcbasso [135.207.130.108]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id LAA17457; Tue, 13 Apr 1999 11:03:20 -0400 (EDT) Message-ID: <035901be85be$c55958c0$6c82cf87@pcbasso.research.att.com> Reply-To: "Andrea Basso" From: "Andrea Basso" To: <4onip-sys@fzi.de>, <4on2-sys@fzi.de>, Subject: IETF/MPEG ad hoc meeting pre-registrations: current list Date: Tue, 13 Apr 1999 11:03:17 -0400 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.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, here is some info on the forthcoming MPEG4/IETF meeting in NY: WEB-SITE A web site with detailed information on directions, agenda, etc. will be available shortly. DOCUMENT SUBMISSION All the documents to be discussed in the meeting should be made available by MONDAY April 19 either by posting them to the mpeg4 over IP mailing list or by providing links to them. IMPORTANT NOTE Anyone planning to participate in this meeting should be familiar with the mpeg4 over IP issues and related documents. If you are planning to join in discussion or consensus taking actions on any of the issues listed on the agenda, please read the documents first. If you have been listed as responsible for bringing up the issues related to any of the documents, please visit the mpeg over IP / MPEG-2 and the rem-conf mailing lists archives and conscientiously collect the major issues that have been raised and discussed so far. The meeting co-chairs reserve the right to cut off anyone who is using WG time to pontificate rather than to advance the work items of the WG. LIST OF INTERESTED PEOPLE Laurent Hermann Steve Casner Guido Franceschini Jan van der Meer Christine Guillemot Paul Christ Anders Klemets Andrea Basso Carsten Herpel Zvi Lifshitz Dominique Curet Roberto Castagno Alexandros Eleftheriadis Hari Calva Norihito Takatori M. Ohno Robert Cohen Reha Civanlar Mukta L. Kar Atul Puri I would like to get confirmation by email for all the people that intend to participate: send email to basso@research.att.com with subject: IETF/MPG4: I WILL ATTEND thanks Andrea Basso, AT&T Labs Research Room 3-219 100 Shultz Drive, Red Bank,NJ 07701 ph: (732) 345-3302 fax (732) 345-3033 basso@research.att.com From rem-conf Tue Apr 13 10:41:24 1999 From rem-conf-request@es.net Tue Apr 13 10:41:24 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10X74A-0003w4-00; Tue, 13 Apr 1999 10:33:42 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10X749-0003vu-00; Tue, 13 Apr 1999 10:33:41 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id KAA22086; Tue, 13 Apr 1999 10:33:39 -0700 (PDT) Message-Id: <3.0.3.32.19990413103338.00ae8740@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 13 Apr 1999 10:33:38 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: Reminder 4/14 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Coding and Transport of Scalable Video Wednesday April 14, 1999, 1:00-2:30 p.m. 405 Soda Hall Please note the time frame of the seminar series has changed!! Wai Tian Tan Elec. Eng. and Comp. Sci. U.C. Berkeley Scalable video compression is suitable for Internet transmissions due to its ability to effect flow control. Examples are source-based rate control for unicast and layered multicast. However, without proper error control, the resulting video may not be of acceptable quality. We will describe some of the unicast experiments we have done over the Internet using bandwidth scalable video compression to motivate the design of our scalable compression scheme with error resilience. We will describe the use of the compression scheme in a unicast setting and present experimental results including comparisons with a forward error correction scheme. Finally we will discuss the applicability of the scheme for multicast transmissions. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Apr 13 12:18:16 1999 From rem-conf-request@es.net Tue Apr 13 12:18:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10X8d8-0005aV-00; Tue, 13 Apr 1999 12:13:54 -0700 Received: from boa.crl.mcmaster.ca [130.113.224.130] (todd) by mail1.es.net with esmtp (Exim 1.81 #2) id 10X8d5-0005aC-00; Tue, 13 Apr 1999 12:13:51 -0700 Received: from localhost (todd@localhost) by boa.crl.mcmaster.ca (8.8.7/8.8.7) with ESMTP id PAA24120; Tue, 13 Apr 1999 15:13:51 -0400 X-Authentication-Warning: boa.crl.mcmaster.ca: todd owned process doing -bs Date: Tue, 13 Apr 1999 15:13:50 -0400 (EDT) From: Terry Todd X-Sender: todd@boa.crl.mcmaster.ca To: itc@ieee.org, comsoc-chapters@ieee.org, multicomm@cc.bellcore.com, commsoft@cc.bellcore.com, sigmedia@bellcore.com, end2end-interest@isi.edu, tcgn@ieee.org, hipparch@sophia.inria.fr, comsoc-gicb@ieee.org, comsoc.tac@tab.ieee.org, ieeetcpc@listserv.utoronto.ca, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, rem-conf@es.net Subject: ICNP'99 (Toronto) submission deadline - May 3 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 ICNP'99 submission deadline is quickly approaching (May 3). Please pass this along to anyone who might be interested. Thanks, Terry +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CALL FOR PAPERS 7th INTERNATIONAL CONFERENCE on NETWORK PROTOCOLS The Royal York Hotel, Toronto, Canada October 31 - November 3, 1999 www.computer.org/conferen/home/icnp/ In just 6 years, ICNP has established itself as one of the premier conferences in the computer networking field. ICNP deals with all aspects of communication protocols, from design and specification, to verification, testing, performance analysis, implementation, and performance tuning. Protocol functions of interest include (but are not limited to) network access, switching, routing, flow and congestion control, multimedia transport, wireless protocols, network security, Web protocols and applications, electronic commerce, network management, interoperability, and internetworking. ICNP uses a single-track format which provides an intimate setting for discussion and debate. The conference is known for it's high quality papers from the research communities of IEEE COMSOC, IEEE Computer Society, and ACM SIGCOMM. To be considered for acceptance, a submission should present a significant contribution in its topic area. Selected papers will be forwarded for "fast track" consideration to IEEE/ACM Transactions on Networking. ICNP also includes panel sessions in which experts in a specific area offer their observations and opinions about a current topic. ICNP'99 will be held in Toronto, whose name is a Huron Indian word meaning "place of meeting". Toronto is Canada's largest city, the capital of the province of Ontario, and one of the most exciting, vibrant, and progressive cities in the world! It's attractions are far too numerous to list. The United Nations has designated Toronto as the world's "most ethnically-diverse city". It has the world's tallest building, the CN Tower, is the third-largest theatre centre in the English-speaking world, and contains over 5,000 restaurants and eateries. Toronto is also a very safe city with many family attractions. ICNP'99 will be held at the famous Royal York Hotel. The Royal York has been in operation since 1929 and is one of the grand hotels of Canada. It is located in the centre of downtown Toronto, a focal point for shopping, culture and nightlife. Important Dates --------------- Paper Submission Deadline: May 3, 1999 Notification of Acceptance: August 2, 1999 Camera Ready Due: August 25, 1999 Tutorials: October 31, 1999 Conference: November 1-3, 1999 Submission Information ---------------------- Submissions will be made via email. Details of the procedure are given at the ICNP'99 web site: www.computer.org/conferen/home/icnp/ General Chair ------------- Johnny Wong, University of Waterloo jwwong@bcr.uwaterloo.ca Technical Program Chairs ------------------------ Joe Bannister, USC Information Sciences Institute Email: joseph@isi.edu Terry Todd, McMaster University Email: todd@mcmaster.ca Tutorial Chair -------------- Kevin Almeroth, UC Santa Barbara Email: almeroth@cs.ucsb.edu Local Arrangements Chair ------------------------ Bart Domzy, Trent University ICNP Steering Committee ----------------------- Mostafa Ammar, Georgia Insitute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland, College Park Krishan Sabnani, Bell Labs Program Committee ----------------- Sudhir Aggarwal, SUNY at Binghamton Kevin Almeroth, UCSB Mostafa Ammar, Georgia Tech Anish Arora, Ohio State Univ. Harmen van As, Vienna Technical Univ. Anindo Banerjea, USC ISI Jose Brustoloni, Bell Labs, Lucent Ken Calvert, Univ. of Kentucky Imrich Chlamtac, Univ. of Texas, Dallas Jorge Cobb, Univ. of Texas, Dallas Jon Crowcroft, University College, London Michael Dahlin, Univ. of Texas, Austin Christophe Diot, Sprint Labs Chris Edmondson-Yurkanan, Univ. of Texas, Austin Mario Gerla, UCLA Li Gong, Sun Microsystems Mohamed Gouda, Univ. of Texas, Austin Mark Handley, AT&T Center for Internet Research at ICSI Teruo Higashino, Osaka Univ. Chao-Ju Jennifer Hou, Ohio State Univ. Allison Mankin, USC ISI-East Ibrahim Matta, Northeastern Univ. Melody Moh, San Jose State Univ. Mart Molle, Univ. of California, Riverside Sanjoy Paul, Bell Labs, Lucent Chunming Qiao, SUNY at Buffalo Luigi Rizzo, Univ. of Pisa Marco Schneider, SBC Technology Resources Gurdip Singh, Kansas State Univ. Martha Steenstrup, BBN David Su, NIST Kenji Suzuki, Kokusai Denshin Denwa Co. Ljiljana Trajkovic, Simon Fraser Univ. Brett Vickers, Rutgers Univ. David Yau, Purdue Univ. Geoffrey Xie, Naval Postgraduate School Ellen Zegura, Georgia Tech Hui Zhang, Carnegie Mellon Univ. ICNP is sponsored by the IEEE Computer Society From rem-conf Wed Apr 14 21:16:22 1999 From rem-conf-request@es.net Wed Apr 14 21:16:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10XdKF-00047z-00; Wed, 14 Apr 1999 21:00:27 -0700 Received: from harrier.prod.itd.earthlink.net [207.217.120.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 10XdKF-00047p-00; Wed, 14 Apr 1999 21:00:27 -0700 Received: from lobos (sdn-ar-001camontP194.dialsprint.net [158.252.195.106]) by harrier.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id VAA08345; Wed, 14 Apr 1999 21:00:24 -0700 (PDT) Message-Id: <199904150400.VAA08345@harrier.prod.itd.earthlink.net> X-Sender: jpolicano@mail.earthlink.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 14 Apr 1999 17:54:52 -0700 To: rem-conf@es.net From: Ryan Thurman Subject: video training info Cc: drmm@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, My name is Ryan Thurman and I am researching some information for a resource guide on the application of videoconferencing in telehealth for Dr. Marlene Maheu.=A0=20 Your answer to the following questions would be very helpful and your= company will be cited appropriately. I am wondering if you have any information on the type of training that is packaged with your equipment.=A0=20 What is the normal procedure for training individuals after they have purchased the equipment? Could you describe some the important points involved in training people to use the videoconferencing equipment? What can you suggest for people who want more training with the equipment? Also, if your company is interested re-seller arrangements with Dr. Maheu please write at and put your vendor information at this address for us:=20 http://cybertowers.com/cgibin/prof.c= gi Thank you for your consideration, Ryan Thurman Research Assistant From rem-conf Wed Apr 14 21:17:50 1999 From rem-conf-request@es.net Wed Apr 14 21:17:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10XdTq-0004CC-00; Wed, 14 Apr 1999 21:10:22 -0700 Received: from mail-green.research.att.com [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 10XdTp-0004C2-00; Wed, 14 Apr 1999 21:10:21 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 4D83D1E00F; Thu, 15 Apr 1999 00:10:20 -0400 (EDT) Received: from pcbasso.research.att.com (nsl-dialup37.research.att.com [135.207.140.164]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id AAA23226; Thu, 15 Apr 1999 00:09:51 -0400 (EDT) Message-ID: <001601be86f5$d90efc20$a48ccf87@pcbasso.research.att.com> Reply-To: "Andrea Basso" From: "Andrea Basso" To: <'4on2andIP-sys@advent.ee.columbia.edu'> Cc: Subject: Web site for the IETF/MPEG meeting in NY Date: Thu, 15 Apr 1999 00:08:04 -0400 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.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Information regarding the forthcoming IETF/MPEG meeting in NY, April 25 1999 can be found at http://www.research.att.com/~mrc/mpeg4.htm Andrea Basso, AT&T Labs Research Room 3-219 100 Shultz Drive, Red Bank,NJ 07701 ph: (732) 345-3302 fax (732) 345-3033 basso@research.att.com From rem-conf Wed Apr 14 21:39:28 1999 From rem-conf-request@es.net Wed Apr 14 21:39:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Xdo3-0005Gf-00; Wed, 14 Apr 1999 21:31:15 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Xdo2-0005GV-00; Wed, 14 Apr 1999 21:31:14 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 097344CE76; Thu, 15 Apr 1999 00:31:14 -0400 (EDT) Received: from pcbasso.research.att.com (nsl-dialup37.research.att.com [135.207.140.164]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id AAA23471; Thu, 15 Apr 1999 00:31:01 -0400 (EDT) Message-ID: <000a01be86f8$c4770b60$a48ccf87@pcbasso.research.att.com> Reply-To: "Andrea Basso" From: "Andrea Basso" To: <4on2andIP-sys@advent.ee.columbia.edu> Cc: Subject: Web site for the IETF/MPEG meeting in NY Date: Thu, 15 Apr 1999 00:30:59 -0400 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.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Information regarding the forthcoming IETF/MPEG meeting in NY, April 25 1999 can be found at http://www.research.att.com/~mrc/mpeg4.htm Andrea Basso, AT&T Labs Research Room 3-219 100 Shultz Drive, Red Bank,NJ 07701 ph: (732) 345-3302 fax (732) 345-3033 basso@research.att.com From rem-conf Thu Apr 15 10:48:52 1999 From rem-conf-request@es.net Thu Apr 15 10:48:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10XqAy-0004nU-00; Thu, 15 Apr 1999 10:43:44 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10XqAx-0004nK-00; Thu, 15 Apr 1999 10:43:43 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id KAA29826; Thu, 15 Apr 1999 10:43:41 -0700 (PDT) Message-Id: <3.0.3.32.19990415104341.0090feb0@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 15 Apr 1999 10:43:41 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 4/21 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar UC Common Authentication Project Wednesday April 21, 1999, 1:00-2:30 p.m. 405 Soda Hall Please note the time frame of the seminar series has changed!! Vance Vaughn Information Systems and Technology, University of California at Berkeley The University of California is engaged in an ambitious project to provide digital credentials to everyone associated with UC including students, faculty, staff, and other members of the university community. I will briefly describe: The underlying technology (e.g., public key/private key encryption, certificates, and PKI) History of the project to date The architecture Current status of the project Some open problems The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Thu Apr 15 21:17:11 1999 From rem-conf-request@es.net Thu Apr 15 21:17:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Xzx3-0001tb-00; Thu, 15 Apr 1999 21:10:01 -0700 Received: from amfjpc.magistracor.org.ar (magistracor.org.ar) [200.32.140.2] by mail1.es.net with smtp (Exim 1.81 #2) id 10Xzx0-0001tP-00; Thu, 15 Apr 1999 21:09:59 -0700 Received: from pookkie by magistracor.org.ar (SMI-8.6/SMI-SVR4) id BAA22021; Fri, 16 Apr 1999 01:07:00 +0300 Message-Id: <199904152207.BAA22021@magistracor.org.ar> From: "Darell" Subject: Extra Cash is No Problem!!! To: wantcash648m@iqemail.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Thu, 15 Apr 1999 23:16:08 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello! I know that a lot of people wish they could stay at home and make thousands of dollars. Well...here is the program to do just that! You may have seen the feature story about this program on a major network TV show several months ago. The network TV show determined that the program explained below is a service and is 100% legal. Take a few minutes to read over all of the information enclosed, MAKE A COPY, then read it again. You won't be sorry! Good Luck! +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Like a lot of people, I was looking for additional income by replying to various advertisements on the Internet and in newspapers. Having worked most of my adult life in the financial profession, I was very impressed by the following proposal: A few weeks ago I received a letter from a fellow attorney that said: I am a retired attorney and about two years ago a man came to me with a letter. The letter he brought to me is the same letter you have before you now. He asked me to review its contents to determine if the letter was legal. I told him I would look it over and get back to him with my opinion. When I first read the letter I thought it was an "off the wall" idea to make money. A week later, I met with my client to discuss the issue. I told him the letter as originally given to me was not 100% legal. Naturally, I was curious about the letter, so he told me how it worked. After hearing the explanation, I decided it was a "long shot", so I decided against participating. However, before my client left my office, I asked him to keep me updated as to his results. About two months later, he called to tell me that he had received more than $800,000 in cash!! Well, I didn't believe him, of course, so he asked me to try the plan and see for myself. I thought about it for a few days and decided that there was not much to lose. I followed the instructions exactly and mailed out 200 letters. Sure enough...the money started coming in! It came slowly at first, but after three weeks, I was getting more mail than I could open in a day. After about 13 weeks, the money stopped coming. I kept a precise record of my earnings and at the end it totaled $868,439.00! I earn a good living as an attorney, but as anyone in the legal profession will tell you, there's a lot of stress that comes with the territory. I decided if things worked out, I would retire >from my practice and play golf. This time I sent out 500 letters. Well...a little more than three months later, I totaled $2,344,178.00!! I met my old client for lunch to find out exactly how it works. He told me that there were a few similar letters going around. What made this one different is the fact that there are seven names on the letter...not five like the others. That factor alone resulted in more returns. The other factor was the advice I gave him in making certain the whole thing was perfectly legal, since no one wants to risk doing anything illegal. I know you must be curious about the little changes I advised him to make for the letter to be legal. Well, when sending out a letter like this one, to be legal, you must sell something if you expect to receive something in return. So, when you send a dollar to each of the seven names on the list, you MUST include a slip of paper saying: "PLEASE ADD ME TO YOUR MAILING LIST" and include YOUR NAME, MAILING ADDRESS, AND E-MAIL ADDRESS. This is the key to the program. The item you will receive is THIS LETTER and the right to earn thousands. =46ollow the simple instructions EXACTLY, and in about three months, you should receive MORE THAN $800,000 IN COLD, HARD CASH!!! 1) IMMEDIATELY send $1.00 to each of the seven names listed below. The SOONER you send the "$1.00 LETTERS", the SOONER you will start getting a return! Wrap the dollar in a note saying: "Please add me to your mailing list". Include YOUR NAME, MAILING ADDRESS, AND E-MAIL ADDRESS. You will receive expert tips on promoting this letter and some excellent BULK EMAIL resources. *Remember...If you don't ask for this service, use of this letter will be illegal for you! 1. Judith T. Mears,PO Box 1273,Piscataway,NJ 08855 2. David Wong,2 Thayer St.Apt.#5B,New York,NY 10040 3. Solutions 101, PO Box 6411, Providence RI 02940-6411 4. T.=46rank,N78W 14573 Appleton Ave.,#227,Menomonee =46alls,WI 53051 5. J. Russell,5201 Kingston Pk.,#6-315,Knoxville,TN 37919 6. E-2000 Marketing, PO Box 15185, East Providence, RI 02915 7. S. Harper, RR 2 Box 39, Sumner, TX. 75486 2) REMOVE THE NAME & ADDRESS NEXT TO #1. at the top of the list and MOVE the other names(#2 thru #7) UP ONE POSITION. Then place YOUR NAME & ADDRESS in the #7 spot. Be careful when you type the addresses. It is suggested that you PROO=46READ to MAKE CERTAIN the names and addresses are correct. 3) When you have completed the above instructions, you may market the letter using the following options: 1. Bulk email 2. U.S. Postal Service 3. =46lyers 4. Post =46REE Classified Ads on the Internet 5. Newsgroups This letter has been proven perfectly legal for all of the above means, as long as you follow the instructions; because you are purchasing membership in an exclusive mailing list. To mail this letter out over the Internet, you can browse through ours and find people to send it to. All you have to do is cut and paste e-mail addresses wherever you are on the Internet. Another method of marketing the letter is using a Bulk E-Mail Service to mail out letters in large volume for you. We suggest using the Bulk E-Mail approach. When you mail your $1 letters you will receive a few recommendations for bulk email companies that will supply you with fresh email addresses. Posting =46REE CLASSI=46IED ADS on the Internet can also achieve results. Simply go to a search engine(e.g. Yahoo, Hot Bot, Lycos, Excite, Infoseek, etc. and type in =46REE CLASSI=46IED ADS. You'll get a list of over 80,000 sites where you can post ads. Remember to use a catchy title like =46REE MONEY, and post your e-mail address. When you get an inquiry, simply e-mail a copy of this letter. The more you send, the more you will make. It's a lot of work...so that's why we recommend using a Bulk E-mail Service. We strongly encourage you to mail this letter to your family and friends. They'll be grateful!! THIS IS A SERVICE AND IS 100% LEGAL. You may refer to: Title 18, Section 1302 & 1342 of the U.S. Postal & Lottery Statute; or check it out with the U.S. Postal Service if you have questions. Let's assume, for example, you get a 7.5% return rate. My first attempt, however, was 9.5%, and my second was more than 11%. 1) When you send out 200 letters, 15 people send you $1.00 ($15.00) 2) Those 15 people mail out 200 letters and 225 people send you $1.00 ($225.00) 3) Those 225 people mail out 200 letters and 3,375 people send you $1.00 ($3,375.00) 4) Those 3,375 people mail out 200 letters, and 50,625 people send you $1.00($50,625.00) 5) Those 50,625 people mail out 200 letters, and 759,375 people send you $1.00 ($759,375.00) 6) At this level, your name drops off the list. Think about it. Look at what you will have received before your name drops off the list. It looks unbelievable, I know. Do the math...see for yourself! Just DO IT and you'll happily believe because you'll receive proof in the form of MANY ONE-DOLLAR BILLS!!! Just make certain that you send a dollar to each of the seven names on the list; including the note asking to be added to their mailing list. Together we will all prosper! Well...you've read this far, so let me ask you a question: Q: What do you have to lose? A: Only $7.00 Don't throw this letter away. Keep it...think about it...and after awhile...YOU WILL TRY IT! I looked at it for over two months, and then I said: "It's only $7...I have to be nuts not to do it". ///////////////////////////////////////////////////////////////// remove at off4now7@yahoo.com ///////////////////////////////////////////////////////////////// From rem-conf Thu Apr 15 23:09:15 1999 From rem-conf-request@es.net Thu Apr 15 23:09:15 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Y1l6-0003CX-00; Thu, 15 Apr 1999 23:05:48 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Y1l5-0003CF-00; Thu, 15 Apr 1999 23:05:47 -0700 Received: from REVELSTOKE ([171.70.119.75]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA11793; Thu, 15 Apr 1999 23:04:46 -0700 (PDT) Date: Thu, 15 Apr 1999 23:04:41 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Re: Confirmation of AVT actions in Minnesota In-Reply-To: Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Tue, 6 Apr 1999, Stephen Casner wrote: > 1. draft-mckay-qcelp-02.txt is a revision to the PureVoice (QCELP) > payload format to address comments received on the previous > version of the draft during working group last call. In > particular, the specification of encryption has been removed. > Since the working group last call actually began about two > meetings ago, one additional week will be allowed for comment, and > then the draft will be submitted for publication as a Proposed > Standard. This working group last call is now completed, and IESG last call will be requested. -- Steve From rem-conf Fri Apr 16 00:43:09 1999 From rem-conf-request@es.net Fri Apr 16 00:43:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Y3EI-0004Q1-00; Fri, 16 Apr 1999 00:40:02 -0700 Received: from galaxy.uci.agh.edu.pl (uci.agh.edu.pl) [149.156.96.9] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10Y3EF-0004Pp-00; Fri, 16 Apr 1999 00:40:00 -0700 Received: from saturn.kt.agh.edu.pl (root@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id JAA06176; Fri, 16 Apr 1999 09:34:51 +0200 (MET DST) Received: from pclyko.kt.agh.edu.pl by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) id AA30653; Fri, 16 Apr 1999 09:25:04 +0200 Address: Mickiewicza 30, 30-059 Krakow, POLAND Message-Id: <3716E5B7.8780FAC8@kt.agh.edu.pl> Date: Fri, 16 Apr 1999 09:24:39 +0200 From: Magdalena Lyko Organization: Katedra Telekomunikacji X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: pl,en Mime-Version: 1.0 To: activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, af-all@atmforum.com, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cellular@comnets.rwth-aachen.de, cif@injector.ca.sandia.gov, cnom@maestro.bellcore.com, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@ieee.org, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, enternet@bbn.com, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@ieee.org, kia@usl.edu, lanoms99@lrg.ufsc.br, MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@ieee.org, xtprelay@cs.concordia.ca Subject: CFP: Broadband Access Conference (BAC'99) Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am sorry if you receive more than one copy of this e-mail! ============================================================ Announcement and Call for Papers BROADBAND ACCESS CONFERENCE (BAC99) Cracow, Poland, October 11-13, 1999 http://BAC99.kt.agh.edu.pl/ Sponsored by IEEE Poland Section and Cracow Communications Society Chapter Rapidly growing demand for Internet resources access and emerging broadband interactive applications attracts telecom operators' and service providers' attention to access technologies: copper (xDSL), fibre (FTTx) and wireles (WLL). The conference addresses a full spectrum of issues related to a residential access - from signal level, through network architectures and their life cycle costs up to live field trial description. The conference will help incumbent operators to determine their own technology migration path to the broadband forefront that will match their current status and prospected market niches. The conference programme is organised in three streamed sessions: * Digital Subscriber Line * Fibre in the Loop * Wireless Solutions Submitted extended abstracts will undergo three independent reviews and accepted papers will appear in the conference proceedings. Tutorials ========= Proposals for tutorials are solicited. Evaluation of proposals will be based on the expertise of the instructors, and on the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the BAC99 chairs. IMPORTANT DATES =============== * Submission of extended abstracts (max. 5 pages) due: May 17, 1999 * Authors notified: June 30, 1999 * Full paper camera ready due: September 10, 1999 SUBMISSION / REGISTRATION ========================= Submit extended abstracts by e_mail to one of the BAC99 chairs. For registration and general information contact a chair of the BAC99 organising Committee, dr Artur Lason. CONFERENCE COMMITTEE ==================== CONFERENCE CHAIRS Prof. Andrzej R. PACH General Chair of BAC'99 Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: pach@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 Prof. Zdzislaw PAPIR Program Chair of BAC'99 Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: papir@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 TECHNICAL PROGRAM COMMITTEE =========================== N.E. ANDERSEN, DSC Communications, Denmark K. ASATANI, Univ. Kogakuin, Japan A. AZCORRA, Univ. Carlos III of Madrid, Spain D. BEM, Wroclaw Univ. Of Technology, Poland W. Y. CHEN, Motorola, USA A. CIZMAR, Univ. Kosice, Slovakia A. DOBROGOWSKI, Poznan Univ. of Technology, Poland A. DZIECH, AGH Cracow Univ., Poland A.L. EKBLAD, Telia, Sweden U. FERRERO, CSELT, Italy K.-P. HO, Chinese Univ., Hong Kong A. JAJSZCZYK, ITTI Ltd. And ATR, Poland T. KESSLER, Deutsche Telecom, Germany K. KIKUSHIMA, NTT, Japan S. KUMAR, Ericsson, USA B. ORTH, Deutsche Telekom, Germany K. PAHLAVAN, Worcester Pol., USA T. POLLET, Bell Alcatel, Belgium M. POUSA, CET, Portugal S. SAY, Next Level Commun., USA A. SIMMONDS, Sheffield Hallam Univ., UK P. SPRUYT, Bell Alcatel, Belgium R. VALADAS, Univ. Aveiro, Portugal M. YANO, Fujitsu, Japan ORGANISING COMMITTEE ==================== Chair: Dr. Artur LASON Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: lason@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 From rem-conf Fri Apr 16 01:44:36 1999 From rem-conf-request@es.net Fri Apr 16 01:44:35 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Y4Az-0005a7-00; Fri, 16 Apr 1999 01:40:41 -0700 Received: from artemis.rus.uni-stuttgart.de [129.69.1.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Y4Ax-0005Zw-00; Fri, 16 Apr 1999 01:40:40 -0700 Received: from ksat10 (ksat10.rus.uni-stuttgart.de [129.69.30.170]) by artemis.rus.uni-stuttgart.de (8.8.8/8.8.8) with SMTP id KAA10462; Fri, 16 Apr 1999 10:06:55 +0200 (MET DST) env-from (christ@rus.uni-stuttgart.de) From: "Paul Christ" To: "Magdalena Lyko" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: RE: Broadband Access Conference (BAC'99) Date: Fri, 16 Apr 1999 10:07:40 +0200 Message-ID: <1e0901be87e0$32be29e0$aa1e4581@ksat10.rus.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-reply-to: <3716E5B7.8780FAC8@kt.agh.edu.pl> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Prof. Pach, in your BAC'99 CFP you do not mention HFC - do you exclude this technology? Yours Paul Christ University of Stuttgart ACTS 037 ATHOC http://www-ks.rus.uni-stuttgart.de/PKB/Projects/ATHOC/Demo_09_10_98/sld001.h tm > -----Original Message----- > From: Magdalena Lyko [mailto:lyko@kt.agh.edu.pl] > Sent: Freitag, 16. April 1999 09:25 > To: activenets_all@ittc.ukansas.edu; ActiveNets_Wire@ittc.ukans.edu; > af-all@atmforum.com; alg@comm.toronto.edu; > amlist@takilab.k.dendai.ac.jp; apc@ee.nthu.edu.tw; apc@eee.nthu.edu.tw; > apc_members@hornbill.ee.nus.sg; apnoms-all@nile.postech.ac.kr; > apnoms-oc@amazon.postech.ac.kr; apnoms-oc@nile.postech.ac.kr; > arpanet-bboard@mc.lcs.mit.edu; atm@bbn.com; atm@sun.com; > bd_email@inesc.pt; bm-list1@cs.ucdavis.edu; cabernet-events@ncl.ac.uk; > cabernet-general@newcastle.ac.uk; ccrc@dworkin.wustl.edu; > celluar@dfv.rwth-aachen.edu; cellular@comnets.rwth-aachen.de; > cif@injector.ca.sandia.gov; cnom@maestro.bellcore.com; > cnon@maestro.bellcore.com; commsoft@cc.belcore.com; > commsoft@cc.bellcore.com; comsoc.bog@tab.ieee.org; > comsoc.tac@tab.ieee.org; comsoc-chapters@ieee.org; comsoc-gicb@ieee.org; > comswtc@gmu.edu; cost237-transport@comp.lancs.ac.uk; > cost237-transport@comp.lancs.at; cpmsoc-gicb@ieee.org; > ctc-members@redbank.tinac.com; dbword@cs.wisc.edu; ekpark@cstp.umkc.edu; > end2end-interest@isi.edu; engp5273@leonis.nus.sg; enternet@bbn.com; > events@teco.edu; fokus-user@fokus.gmd.de; f-troup@codex.cis.upenn.edu; > ftroup@dsl.cis.upenn.edu; gcomlist1@manjaro.ece.iit.edu; > giga@tele.pitt.edu; g-troup@ccrc.wustl.edu; heads@hpovua.org; > hipparch@entropy.inria.fr; hipparch@sophia.inria.fr; > Hossam.Afifi@enst-bretagne.fr; ieee.announce@bellcore.com; > ieee_rtc_list@cs.tamu.edu; ieeetcpc@ccvm.sunysb.edu; ietf@ietf.org; > ifip-6-1distr@run.montefiore.ulg.ac.be; im-oc@doc.ic.ac.uk; > int-serv@isi.edu; isadsoc@fokus.gmd.de; issll@mercury.lcs.mit.edu; > itc@fokus.gmd.de; itc@ieee.org; kia@usl.edu; lanoms99@lrg.ufsc.br; > MariaLuisa.Rossari@cselt.it; members@hpovua.org; members@tmforum.org; > mobile-ip@tadpole.com; modern-heuristics@uk.ac.mailbase.ucdavis.edu; > multicomm@cc.bellcore.com; multicomm@research.panasonic.com; > nm-australia@amazon.postech.ac.kr; nmkorea@amazon.postech.ac.kr; > Omar.Elloumi@enst-bretagne.fr; opensig-announce@ctr.columbia.edu; > osimcast@bbn.com; performance@haven.epm.ornl.gov; prs@masi.ibp.fr; > qos-iso@mci.org.uk; qosws@dstc.edu.au; rem-conf@es.net; reres@laas.fr; > s.low@ee.mu.oz.au; sb.all@ieee.org; sc6wg4@ntd.comsat.com; > sig-dce@opengroup.org; sigmedia@bellcore.com; tccc@ieee.org; > tchen@seas.smu.edu; testnet@canarie.ca; tm_member@ns.ieice.or.jp; > wwlu@ieee.org; xtprelay@cs.concordia.ca > Subject: CFP: Broadband Access Conference (BAC'99) > > > I am sorry if you receive more than one copy of this e-mail! > ============================================================ > > > > Announcement and Call for Papers > > BROADBAND ACCESS CONFERENCE (BAC99) > > Cracow, Poland, October 11-13, 1999 > > http://BAC99.kt.agh.edu.pl/ > > > Sponsored by IEEE Poland Section and Cracow Communications Society > Chapter > > > > Rapidly growing demand for Internet resources access and emerging > broadband > interactive applications attracts telecom operators' and service > providers' > attention to access technologies: copper (xDSL), fibre (FTTx) and > wireles (WLL). > > The conference addresses a full spectrum of issues related to a > residential > access - from signal level, through network architectures and their life > cycle > costs up to live field trial description. > > The conference will help incumbent operators to determine their own > technology > migration path to the broadband forefront that will match their current > status > and prospected market niches. > > The conference programme is organised in three streamed sessions: > > * Digital Subscriber Line > > * Fibre in the Loop > > * Wireless Solutions > > Submitted extended abstracts will undergo three independent reviews > and accepted papers will appear in the conference proceedings. > > Tutorials > ========= > Proposals for tutorials are solicited. Evaluation of proposals will be > based on > the expertise of the instructors, and on the subject matter. Potential > instructors are requested to submit a tutorial proposal of at most 5 > pages, > including a biographical sketch, to the BAC99 chairs. > > > > IMPORTANT DATES > =============== > > * Submission of extended abstracts (max. 5 pages) due: May 17, > 1999 > > * Authors notified: June 30, 1999 > > * Full paper camera ready due: September 10, 1999 > > > SUBMISSION / REGISTRATION > ========================= > Submit extended abstracts by e_mail to one of the BAC99 chairs. > For registration and general information contact a chair of the BAC99 > organising Committee, dr Artur Lason. > > CONFERENCE COMMITTEE > ==================== > > CONFERENCE CHAIRS > > Prof. Andrzej R. PACH > General Chair of BAC'99 > > Department of Telecommunications > AGH Cracow University > Al. Mickiewicza 30 > 30-059 Krakow, Poland > Email: pach@kt.agh.edu.pl > Tel: +48 12 634 5582 > Fax: +48 12 634 2372 > > Prof. Zdzislaw PAPIR > Program Chair of BAC'99 > > Department of Telecommunications > AGH Cracow University > Al. Mickiewicza 30 > 30-059 Krakow, Poland > Email: papir@kt.agh.edu.pl > Tel: +48 12 634 5582 > Fax: +48 12 634 2372 > > > TECHNICAL PROGRAM COMMITTEE > =========================== > N.E. ANDERSEN, DSC Communications, Denmark > K. ASATANI, Univ. Kogakuin, Japan > A. AZCORRA, Univ. Carlos III of Madrid, Spain > D. BEM, Wroclaw Univ. Of Technology, Poland > W. Y. CHEN, Motorola, USA > A. CIZMAR, Univ. Kosice, Slovakia > A. DOBROGOWSKI, Poznan Univ. of Technology, Poland > A. DZIECH, AGH Cracow Univ., Poland > A.L. EKBLAD, Telia, Sweden > U. FERRERO, CSELT, Italy > K.-P. HO, Chinese Univ., Hong Kong > A. JAJSZCZYK, ITTI Ltd. And ATR, Poland > T. KESSLER, Deutsche Telecom, Germany > K. KIKUSHIMA, NTT, Japan > S. KUMAR, Ericsson, USA > B. ORTH, Deutsche Telekom, Germany > K. PAHLAVAN, Worcester Pol., USA > T. POLLET, Bell Alcatel, Belgium > M. POUSA, CET, Portugal > S. SAY, Next Level Commun., USA > A. SIMMONDS, Sheffield Hallam Univ., UK > P. SPRUYT, Bell Alcatel, Belgium > R. VALADAS, Univ. Aveiro, Portugal > M. YANO, Fujitsu, Japan > > > ORGANISING COMMITTEE > ==================== > Chair: Dr. Artur LASON > Department of Telecommunications > AGH Cracow University > Al. Mickiewicza 30 > 30-059 Krakow, Poland > > Email: lason@kt.agh.edu.pl > Tel: +48 12 634 5582 > Fax: +48 12 634 2372 > > From rem-conf Fri Apr 16 04:22:33 1999 From rem-conf-request@es.net Fri Apr 16 04:22:28 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Y6fA-0007AS-00; Fri, 16 Apr 1999 04:20:00 -0700 Received: from galaxy.uci.agh.edu.pl (uci.agh.edu.pl) [149.156.96.9] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10Y6et-0007AG-00; Fri, 16 Apr 1999 04:19:44 -0700 Received: from saturn.kt.agh.edu.pl (root@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id NAA13442; Fri, 16 Apr 1999 13:15:30 +0200 (MET DST) Received: from pclyko.kt.agh.edu.pl by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) id AA29107; Fri, 16 Apr 1999 13:14:18 +0200 Address: Mickiewicza 30, 30-059 Krakow, POLAND Message-Id: <37171B72.8A1B4C68@kt.agh.edu.pl> Date: Fri, 16 Apr 1999 13:13:54 +0200 From: Magdalena Lyko Organization: Katedra Telekomunikacji X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: pl,en Mime-Version: 1.0 To: MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@ieee.org, performance@haven.epm.ornl.gov, qos-iso@mci.org.uk, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, multicomm@cc.bellcore.co, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, qosws@dstc.edu.au, rem-conf@es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@ieee.org, sig-dce@opengroup.org Subject: CFP: Broadband Access Conference (BAC'99) Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am sorry if you receive more than one copy of this e-mail! ============================================================ Announcement and Call for Papers BROADBAND ACCESS CONFERENCE (BAC99) Cracow, Poland, October 11-13, 1999 http://BAC99.kt.agh.edu.pl/ Sponsored by IEEE Poland Section and Cracow Communications Society Chapter Rapidly growing demand for Internet resources access and emerging broadband interactive applications attracts telecom operators' and service providers' attention to access technologies: copper (xDSL), fibre (FTTx) and wireles (WLL). The conference addresses a full spectrum of issues related to a residential access - from signal level, through network architectures and their life cycle costs up to live field trial description. The conference will help incumbent operators to determine their own technology migration path to the broadband forefront that will match their current status and prospected market niches. The conference programme is organised in three streamed sessions: * Digital Subscriber Line * Fibre in the Loop * Wireless Solutions Submitted extended abstracts will undergo three independent reviews and accepted papers will appear in the conference proceedings. Tutorials ========= Proposals for tutorials are solicited. Evaluation of proposals will be based on the expertise of the instructors, and on the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the BAC99 chairs. IMPORTANT DATES =============== * Submission of extended abstracts (max. 5 pages) due: May 17, 1999 * Authors notified: June 30, 1999 * Full paper camera ready due: September 10, 1999 SUBMISSION / REGISTRATION ========================= Submit extended abstracts by e_mail to one of the BAC99 chairs. For registration and general information contact a chair of the BAC99 organising Committee, dr Artur Lason. CONFERENCE COMMITTEE ==================== CONFERENCE CHAIRS Prof. Andrzej R. PACH General Chair of BAC'99 Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: pach@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 Prof. Zdzislaw PAPIR Program Chair of BAC'99 Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: papir@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 TECHNICAL PROGRAM COMMITTEE =========================== N.E. ANDERSEN, DSC Communications, Denmark K. ASATANI, Univ. Kogakuin, Japan A. AZCORRA, Univ. Carlos III of Madrid, Spain D. BEM, Wroclaw Univ. Of Technology, Poland W. Y. CHEN, Motorola, USA A. CIZMAR, Univ. Kosice, Slovakia A. DOBROGOWSKI, Poznan Univ. of Technology, Poland A. DZIECH, AGH Cracow Univ., Poland A.L. EKBLAD, Telia, Sweden U. FERRERO, CSELT, Italy K.-P. HO, Chinese Univ., Hong Kong A. JAJSZCZYK, ITTI Ltd. And ATR, Poland T. KESSLER, Deutsche Telecom, Germany K. KIKUSHIMA, NTT, Japan S. KUMAR, Ericsson, USA B. ORTH, Deutsche Telekom, Germany K. PAHLAVAN, Worcester Pol., USA T. POLLET, Bell Alcatel, Belgium M. POUSA, CET, Portugal S. SAY, Next Level Commun., USA A. SIMMONDS, Sheffield Hallam Univ., UK P. SPRUYT, Bell Alcatel, Belgium R. VALADAS, Univ. Aveiro, Portugal M. YANO, Fujitsu, Japan ORGANISING COMMITTEE ==================== Chair: Dr. Artur LASON Department of Telecommunications AGH Cracow University Al. Mickiewicza 30 30-059 Krakow, Poland Email: lason@kt.agh.edu.pl Tel: +48 12 634 5582 Fax: +48 12 634 2372 From rem-conf Fri Apr 16 06:26:11 1999 From rem-conf-request@es.net Fri Apr 16 06:26:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Y8b3-0000zE-00; Fri, 16 Apr 1999 06:23:53 -0700 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Y8b2-0000z4-00; Fri, 16 Apr 1999 06:23:52 -0700 Received: [from pobox2.mot.com (pobox2.mot.com [129.188.137.195]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id IAA10461 for ; Fri, 16 Apr 1999 08:23:51 -0500 (CDT)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with SMTP id IAA24402 for ; Fri, 16 Apr 1999 08:22:12 -0500 (CDT)] Received: from rex.miel.mot.com by hpux4.miel.mot.com with SMTP id AA24932 (5.67b/IDA-1.6 for rem-conf@es.net); Fri, 16 Apr 1999 18:45:49 +0500 Received: from earth (earth.miel.mot.com) by rex.miel.mot.com with SMTP id AA21347 (5.67b/IDA-1.5 for casner@cisco.com); Fri, 16 Apr 1999 18:54:43 +0530 Sender: gvjohn@miel.mot.com Message-Id: <37173804.3EF@miel.mot.com> Date: Fri, 16 Apr 1999 18:45:48 +0530 From: Geevarghese John Organization: Motorola India Electronics Ltd, Bangalore X-Mailer: Mozilla 3.01 (X11; I; HP-UX A.09.01 9000/715) Mime-Version: 1.0 To: rem-conf@es.net Cc: casner@cisco.com Subject: [Fwd: [Fwd: [Fwd: Re: RTP/UDP/IP header compression]]] Content-Type: multipart/mixed; boundary="------------751D4C376E62" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------751D4C376E62 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Please reply to the below mentioned question which I asked steve. I prefer more experts commenting on this, if possible Just to get your different view on this. GVJ --------------751D4C376E62 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from rex.miel.mot.com by earth.miel.mot.com with SMTP id AA04410 (5.67b/IDA-1.5 for gvjohn); Fri, 16 Apr 1999 18:27:33 +0530 Return-Path: Received: from earth (earth.miel.mot.com) by rex.miel.mot.com with SMTP id AA21162 (5.67b/IDA-1.5 for gvjohn@earth.miel.mot.com); Fri, 16 Apr 1999 18:36:21 +0530 Sender: gvjohn@miel.mot.com Message-Id: <371733B6.25D0@miel.mot.com> Date: Fri, 16 Apr 1999 18:27:26 +0530 From: Geevarghese John Organization: Motorola India Electronics Ltd, Bangalore X-Mailer: Mozilla 3.01 (X11; I; HP-UX A.09.01 9000/715) Mime-Version: 1.0 To: Stephen Casner Cc: gvjohn@miel.mot.com Subject: [Fwd: [Fwd: Re: RTP/UDP/IP header compression]] Content-Type: multipart/mixed; boundary="------------2461755D481B" This is a multi-part message in MIME format. --------------2461755D481B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, After a long time, this time it may bethe same question for you but I could not get the answer .. The solution you suggested for the problem which I pointed out earlier (below enclosed mail) your or IETF recommendation was we will have negotiation taking place over Frame Relay also .. By this method are we not depending on the DLC protocol for our compression protocol to work. Is it not a dependancy on the DLC layer ? I can understand the philosophy of having negotiation as a solution for the problem rather than exchanging flags with each CONTEXT_STATE packet why can't we have the negotiation at the protocol layer itself ? or something similar to this rather than modifying all DLC protocols ... and troubling those things. Please reply to this question . I could not get a good solution for this .. B Rgds GVJohn Stephen Casner wrote: > > > > Hope you will update me with the solution of my last problem I pointed > > out > > with the CONTEXT_STATE packet when it is available.. > > The feedback that I got at IETF was that it might be appropriate to > define a means to negotiate this within FR. I think that should be > tied in with the registration of the type numbers as discussed above. > Also, we need to think about whether there should be more negotiation > of parameters as in PPP rather than just an error message as you have > proposed. > -- Steve The pointed out problem below mentioned ----------------------------- --------------2461755D481B Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from rex.miel.mot.com by earth.miel.mot.com with SMTP id AA25735 (5.67b/IDA-1.5 for gvjohn); Mon, 15 Mar 1999 20:22:04 +0530 Return-Path: Received: from earth (earth.miel.mot.com) by rex.miel.mot.com with SMTP id AA06722 (5.67b/IDA-1.5 for gvjohn@earth.miel.mot.com); Mon, 15 Mar 1999 20:27:46 +0530 Sender: gvjohn@miel.mot.com Message-Id: <36ED1E8E.6C01@miel.mot.com> Date: Mon, 15 Mar 1999 20:21:58 +0530 From: Geevarghese John Organization: Motorola India Electronics Ltd, Bangalore X-Mailer: Mozilla 3.01 (X11; I; HP-UX A.09.01 9000/715) Mime-Version: 1.0 To: casner@cisco.com Cc: gvjohn@miel.mot.com Subject: [Fwd: Re: RTP/UDP/IP header compression] Content-Type: multipart/mixed; boundary="------------47A0405A5BE4" This is a multi-part message in MIME format. --------------47A0405A5BE4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, To be more clear on my point - adding error message (at leaset one error message) info in the CONTEXT_STATE packet .. consider a scenario where compressor sends a FULL_HEADER and that was missed while transfer and next packet compressor sends as CRTP .. In the above example decompressor is expected to send a CONTEXT_STATE packet .. but consider another case .. where compressor sends a FULL_HEADER packet (CRTP ) with CID n where decompressor context list size is k and k < n .. what decompressor should assume, should it send a CONTEXT_STATE packet .. If yes decompressor get and FULL_HEADER again but if it drops the packet more compressed packets will arrive .... How do we recover .. Why I am suggesting a error message because compressor and decompressor can engage in compressed packete transfer correctly as long as there is no mismatch like this even if their context list size was not matching ... For small vendors even if the configuration permit the 16-bit CID value there may be maximum limit of 4098 or XYZ size limit which is less that 65535 ... if both end do not match on this, above mentioned problems can arise and since the protocol continue to work correctly till the mismatch occurs, I feel there should be error message indication ... Would you agree on this or what do you suggest on this problem ... Rgds GVJ --------------47A0405A5BE4 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from rex.miel.mot.com by earth.miel.mot.com with SMTP id AA05268 (5.67b/IDA-1.5 for gvjohn); Mon, 15 Mar 1999 12:16:38 +0530 Return-Path: Received: from earth (earth.miel.mot.com) by rex.miel.mot.com with SMTP id AA00806 (5.67b/IDA-1.5 for gvjohn@earth.miel.mot.com); Mon, 15 Mar 1999 12:22:17 +0530 Sender: gvjohn@miel.mot.com Message-Id: <36ECACC7.2702@miel.mot.com> Date: Mon, 15 Mar 1999 12:16:31 +0530 From: Geevarghese John Organization: Motorola India Electronics Ltd, Bangalore X-Mailer: Mozilla 3.01 (X11; I; HP-UX A.09.01 9000/715) Mime-Version: 1.0 To: Stephen Casner Cc: gvjohn@miel.mot.com Subject: Re: RTP/UDP/IP header compression References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > We have PPP negotiation to exchange the Context ID size > > what about other link layers ..for example Frame Relay .. > > CONTEXT_STATE packet do not permit me to inform the other end that > > CONTEXT ID size mismatch occured .. > > Sending FULL_HEADER is not the solution for it.. > > I would say this is a PPP error. If you have successfully negotiated > a particular size, and then the other end sends you the wrong size, > then you should treat it like a failure to follow any other PPP > negotiation. I am not a PPP expert, but I would guess that the > appropriate response is to reset the connection and renegotiate > without the use of CRTP. > No, PPP is not there in my example Consider the example of Frame Relay where no negotiation takes place ... User configuration is the other alternative ... but if there is a mismatch I feel both ends will keep on sending CONTEXT_STATE packet .. and many more issues like that .. --------------47A0405A5BE4-- --------------2461755D481B-- --------------751D4C376E62-- From rem-conf Fri Apr 16 07:04:06 1999 From rem-conf-request@es.net Fri Apr 16 07:04:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Y9CD-0001lO-00; Fri, 16 Apr 1999 07:02:17 -0700 Received: from lrg-gw.lrg.ufsc.br (lrg.ufsc.br) [150.162.1.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Y9C8-0001lE-00; Fri, 16 Apr 1999 07:02:14 -0700 Received: (from westphal@localhost) by lrg.ufsc.br (8.7.5/8.7.3) id KAA05520; Fri, 16 Apr 1999 10:06:58 -0300 (EST) Date: Fri, 16 Apr 1999 10:06:58 -0300 (EST) From: "Prof. Carlos B. Westphall" Message-Id: <199904161306.KAA05520@lrg.ufsc.br> To: activenets_all@ittc.ukansas.edu, ActiveNets_Wire@ittc.ukans.edu, af-all@atmforum.com, alg@comm.toronto.edu, amlist@takilab.k.dendai.ac.jp, apc@ee.nthu.edu.tw, apc@eee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, apnoms-all@nile.postech.ac.kr, apnoms-oc@amazon.postech.ac.kr, apnoms-oc@nile.postech.ac.kr, arpanet-bboard@mc.lcs.mit.edu, atm@BBN.COM, atm@sun.com, bd_email@inesc.pt, bm-list1@cs.ucdavis.edu, cabernet-events@ncl.ac.uk, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, celluar@dfv.rwth-aachen.edu, cellular@comnets.rwth-aachen.de, cif@injector.ca.sandia.gov, cnom@maestro.bellcore.com, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@IEEE.ORG, comsoc-gicb@IEEE.ORG, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, cost237-transport@comp.lancs.at, cpmsoc-gicb@IEEE.ORG, ctc-members@redbank.tinac.com, dbword@cs.wisc.edu, ekpark@cstp.umkc.edu, end2end-interest@isi.edu, engp5273@leonis.nus.sg, enternet@BBN.COM, events@teco.edu, fokus-user@fokus.gmd.de, f-troup@codex.cis.upenn.edu, ftroup@dsl.cis.upenn.edu, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, g-troup@ccrc.wustl.edu, heads@hpovua.org, hipparch@entropy.inria.fr, hipparch@sophia.inria.fr, Hossam.Afifi@enst-bretagne.fr, ieee.announce@bellcore.com, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, ifip-6-1distr@run.montefiore.ulg.ac.be, im-oc@doc.ic.ac.uk, int-serv@isi.edu, isadsoc@fokus.gmd.de, issll@mercury.lcs.mit.edu, itc@fokus.gmd.de, itc@IEEE.ORG, kia@usl.edu, lanoms99@lrg.ufsc.br, MariaLuisa.Rossari@cselt.it, members@hpovua.org, members@tmforum.org, mobile-ip@tadpole.com, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, multicomm@research.panasonic.com, nm-australia@amazon.postech.ac.kr, nmkorea@amazon.postech.ac.kr, Omar.Elloumi@enst-bretagne.fr, opensig-announce@ctr.columbia.edu, osimcast@BBN.COM, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qos-iso@mci.org.uk, qosws@dstc.edu.au, rem-conf@lrg.ufsc.br Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list es.net, reres@laas.fr, s.low@ee.mu.oz.au, sb.all@IEEE.ORG, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@IEEE.ORG, tchen@seas.smu.edu, testnet@canarie.ca, tm_member@ns.ieice.or.jp, wwlu@IEEE.ORG, xtprelay@cs.concordia.ca, lyko@kt.agh.edu.pl Subject: IEEE LANOMS Cc: lanoms99 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-MD5: JJsPfFUeimIXJFQS03hZOA== *********** PLEASE, OBSERVE THE NEW DEADLINE MAY 06, 1999 = ************** **** I am sorry if you receive more than one copy of this e-mail = ********* *************************************************************************= ** LANOMS=B499 IEEE Latin American Network Operations and Management Symposium Rio de Janeiro - Brazil, December 03 - 04, 1999. =20 "NETWORK MANAGEMENT FOR THE NEW WORLD"=20 =20 Call for Papers =20 =20 The First Latin American Network Operations and Management Symposium -=20 LANOMS, to be held in Rio de Janeiro on the turn of the millennium=20 is the result of the great success of the events in the area of=20 network management known as NOMS and APNOMS. NOMS (Network Operations=20 and Management Symposium) was originally created ten years ago in=20 New Orleans, USA, and nowadays constitutes a worldwide event for=20 the researches in the area of network management. Recently, the=20 Asia/Pacific community promoted the APNOMS (Asia-Pacific=20 Network Operations and Management Symposium), which is an event more=20 oriented to the research and development community in that continent.=20 Within this context, we will promote the first LANOMS=20 (http://www.lrg.ufsc.br/~lanoms99) in order to stimulate the=20 researches in Latin America. It is important to emphasize that this event will be held in the same hotel and two days before the=20 GLOBECOM. In the last few years, we have been witnessing an increasing demand on=20 topics associated with Network Management in national and international=20 events, organized mainly in Brazil, Mexico, Chile, Argentina, and = Uruguay.=20 As a consequence, we observed in Latin America a solid necessity of a=20 specific event where there might be room to debate the main issues = involving the=20 area of Network Management. For obvious reasons, the organization of=20 LANOMS will be tuned with NOMS and APNOMS to even stimulate the = participation=20 of the Latin American community in these events. As LANOMS derives from NOMS, keeping its original characteristics, it will create a forum=20 which is more specific to the requirements of Latin America in the area of Network Management involving telecommunication companies,=20 academic institutions, service providers and equipment vendors. Although organized in Latin America, LANOMS will be opened to participants=20 (researchers, developers, investors, etc) from other continents who are interested in having, or already have, research or commercial=20 liaisons in Latin America. The objectives of LANOMS include, but are not limited to: * to satisfy an increasing necessity of organizing a specific=20 event on network management in Latin America in order to=20 divulge the researches currently developed; * to identify the problems and solutions specific to the area=20 of network management; * to make viable the solutions proposed by the international=20 community to Latin America and vice-versa; and=20 * to expose the potentialities of the Network Management area; Submissions should be complete, full-length papers and should not exceed = = =20 12 pages. Electronic submission of papers is strongly encouraged. Full=20 instructions for the electronic submissions will be available soon on = the LANOMS web page.=20 Important Dates: Paper due: May 06, 1999 Notification: Aug. 06, 1999 Camera Ready: Sep. 06, 1999 Suggested Topics: + Artificial Intelligence Solutions for Network Management + Broadband Network Management Implementation + Business and Service Management + CORBA Support for Distributed Management + Distributed Network and Service Management + Enterprise Management + Experiences in Management Environments + Intelligent Agents + Interoperability and Platforms + Network Operation and Management Solutions for Latin America + Neural Networks Technologies + New Technologies and Methodologies + Proactive Management + Protocol Specifications + SONET/SDH/ATM + Security Management + Telecommunication Policies + Traffic and Performance Management + TMN Technology + Web-Based Management=20 Committee Members --------- ------- General and TCP Chair: =20 Carlos Becker Westphall, Brazil=20 =20 TPC Co-Chairs: =20 Luiz Fernando Kormann, Brazil=20 Mirela Sechi Moretti Annoni Notare, Brazil=20 =20 Publication Chair: =20 Bernardo Goncalves Riso, Brazil=20 =20 Publicity Chair: =20 Juan Carlos Miguez, Uruguay=20 =20 Finance Chair: =20 Fernando Augusto da Silva Cruz, Brazil=20 Joao Bosco Mangueira Sobral, Brazil=20 =20 Local Arrangements Chair: =20 Michael Stanton, Brazil =20 =20 IEEE CNOM Chair:=20 Veli Sahin, USA=20 =20 International Liasions:=20 Africa: J. Roos, South Africa=20 Asia: J. Hong, Korea =20 Europe: E. Bagnasco, Italy =20 N. America: S. Aidarous, USA =20 Oceania: P. Ray, Australia =20 =20 Advisory Board:=20 B. Meandzijas, USA=20 D. Zuckerman, USA=20 M. Ejiri, Japan=20 M. Yoshida, Japan=20 R. Saracco, Italy=20 S. Goyal, USA=20 V. Sahin, USA W. Zimmer, Germany=20 =20 Technical Program Committee=20 Adarsh Sethi (USA)=20 Alan Mckinlay (UK)=20 Alejandro Miralles (Chile) Behcet Sarikaya (Japan)=20 Carlos de Lara (Mexico)=20 Carlos E. Caicedo (Colombia)=20 Eduard Pinnes (USA)=20 Edmundo R. Madeira (Brazil)=20 Elias Procopio Duarte Junior (Brazil)=20 Gabriel Jakobson (USA)=20 German Goldszmidt (USA)=20 Guy Pujolle (France) =20 Heinz-Gerd Hegering (Germany)=20 Joberto S. Barbosa Martins (Brazil)=20 Jong-Tae Park (Korea)=20 Jose Marcos Nogueira (Brazil)=20 Jose Neuman de Souza (Brazil)=20 Keith-Stuart von Mecklenburg (UK)=20 Leonor W. Chaux (Colombia)=20 Manu Malek (USA)=20 Manoel C. Penna (Brazil) =20 Michael Bauer (Canada)=20 Michele Sibilla (France)=20 Nelson Fonseca (Brazil)=20 Osvaldo Bianchi (Argentina)=20 Paulo Gomide Cohn (Brazil)=20 Raul Monge (Chile)=20 Robert Weihmayer (USA)=20 Roberto Vercelli (Italy) =20 Varoozh Harikian (Belgium)=20 =20 This event is Technically Co-Sponsored by the IEEE ComSoc. Contact Address: Carlos Becker Westphall (LANOMS=B499 General Chair) Federal University of Santa Catarina - UFSC Technological Center - CTC Network and Management Laboratory - LRG P.O.Box 476=20 88040 970 Florianopolis - SC BRAZIL lanoms99@lrg.ufsc.br =20 http://www.lrg.ufsc.br/~lanoms99 From rem-conf Sun Apr 18 09:35:40 1999 From rem-conf-request@es.net Sun Apr 18 09:35:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10YuM0-0002xJ-00; Sun, 18 Apr 1999 09:23:32 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10YuLy-0002x9-00; Sun, 18 Apr 1999 09:23:30 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA00926 for ; Sun, 18 Apr 1999 12:23:29 -0400 (EDT) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA01099 for ; Sun, 18 Apr 1999 12:23:28 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <371A0700.D5477A6C@cs.columbia.edu> Date: Sun, 18 Apr 1999 12:23:28 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Shared web browsing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Any recommendations for a tool that allows "guided web tours" or "shared/joint web browsing", where the URLs viewed by, say, the instructor guide the behavior of other web browsers? I remember such a tool, written in France, being discussed for one of the early WWW conferences, but can't find a ready reference. Powwow has something like that, but only for Windows and as part of a closed package. imeet.com offers a commercial service along these lines, paid by the hour. Another one I found is a Java class at http://cdo.weblinq.com/~tiger/code/java/Controller/index.html, but there must be better solutions. Thanks. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Sun Apr 18 10:33:41 1999 From rem-conf-request@es.net Sun Apr 18 10:33:41 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10YvNx-0003u5-00; Sun, 18 Apr 1999 10:29:37 -0700 Received: from aries.dif.um.es (aries.) [155.54.12.152] by mail1.es.net with smtp (Exim 1.81 #2) id 10YvNv-0003tv-00; Sun, 18 Apr 1999 10:29:36 -0700 Received: from dif.um.es by aries. (SMI-8.6/SMI-SVR4) id TAA06654; Sun, 18 Apr 1999 19:18:19 +0100 Message-Id: <199904181818.TAA06654@aries.> X-Mailer: exmh version 2.0.2 From: Pedro Miguel Ruiz Martinez To: rem-conf@es.net Subject: Re: Shared web browsing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Apr 1999 19:17:16 +0200 Sender: pedrom@dif.um.es X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Any recommendations for a tool that allows "guided web tours" or >"shared/joint web browsing", where the URLs viewed by, say, the >instructor guide the behavior of other web browsers? I remember such a >tool, written in France, being discussed for one of the early WWW >conferences, but can't find a ready reference. Powwow has something like >that, but only for Windows and as part of a closed package. imeet.com >offers a commercial service along these lines, paid by the hour. Another >one I found is a Java class at >http://cdo.weblinq.com/~tiger/code/java/Controller/index.html, but there >must be better solutions. >Thanks. >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs I know about mWeb. I think this tool could fit very well on your previous description. Check this URL: http://www.cdt.luth.se/mstar/tools.html -------------------------------------------------------------------- Pedro Miguel Ruiz Martinez Inv. Aplic. Colaborativas y MBone. Laboratorio de Redes Facultad de Informatica Universidad de Murcia Tlf +34 968364644 Spain -------------------------------------------------------------------- From rem-conf Sun Apr 18 10:40:29 1999 From rem-conf-request@es.net Sun Apr 18 10:40:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10YvWU-00046F-00; Sun, 18 Apr 1999 10:38:26 -0700 Received: from dns1.transbay.net (transbay.net) [209.133.53.2] (dwinet) by mail1.es.net with esmtp (Exim 1.81 #2) id 10YvWS-000464-00; Sun, 18 Apr 1999 10:38:25 -0700 Received: from localhost (dwinet@localhost) by transbay.net (8.9.1/8.8.8) with SMTP id KAA23444; Sun, 18 Apr 1999 10:41:26 -0700 (PDT) (envelope-from dwinet@synergy.transbay.net) Date: Sun, 18 Apr 1999 10:41:26 -0700 (PDT) From: David Winet To: Pedro Miguel Ruiz Martinez cc: rem-conf@es.net Subject: Re: Shared web browsing In-Reply-To: <199904181818.TAA06654@aries.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Search no more: http://www.conavigator.com is a no-brainer! On Sun, 18 Apr 1999, Pedro Miguel Ruiz Martinez wrote: > > >Any recommendations for a tool that allows "guided web tours" or > >"shared/joint web browsing", where the URLs viewed by, say, the > >instructor guide the behavior of other web browsers? I remember such a > >tool, written in France, being discussed for one of the early WWW > >conferences, but can't find a ready reference. Powwow has something like > >that, but only for Windows and as part of a closed package. imeet.com > >offers a commercial service along these lines, paid by the hour. Another > >one I found is a Java class at > >http://cdo.weblinq.com/~tiger/code/java/Controller/index.html, but there > >must be better solutions. > > >Thanks. > >-- > >Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > I know about mWeb. I think this tool could fit very well on your previous > description. > > Check this URL: http://www.cdt.luth.se/mstar/tools.html > > > > -------------------------------------------------------------------- > Pedro Miguel Ruiz Martinez > Inv. Aplic. Colaborativas y MBone. > Laboratorio de Redes > Facultad de Informatica > Universidad de Murcia > Tlf +34 968364644 > Spain > -------------------------------------------------------------------- > > > > From rem-conf Sun Apr 18 10:43:32 1999 From rem-conf-request@es.net Sun Apr 18 10:43:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10YvZH-0004GE-00; Sun, 18 Apr 1999 10:41:19 -0700 Received: from basil.cdt.luth.se [130.240.64.67] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10YvZG-0004Fz-00; Sun, 18 Apr 1999 10:41:18 -0700 Received: from cdt.luth.se (p044.modem.luth.se [130.240.41.44]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id TAA24388; Sun, 18 Apr 1999 19:41:00 +0200 (MET DST) Message-ID: <371A1A68.E3720138@cdt.luth.se> Date: Sun, 18 Apr 1999 19:46:16 +0200 From: Peter Parnes Organization: Centre for Distance-spanning =?iso-8859-1?Q?Technology=2FLule=E5?= University of Technology, Marratech AB X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pedro Miguel Ruiz Martinez CC: rem-conf@es.net Subject: Re: Shared web browsing References: <199904181818.TAA06654@aries.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > mWeb mWeb is now part of the product Marratech Pro, mPro from Marratech AB in Sweden. A trial version can be downloaded from www.marratech.com. And yes, mPro supports shared browsing through its built in web browser (it also support loads of other things like audio, video, whiteboard, chat, shared applications etc etc etc :-) /P From rem-conf Sun Apr 18 18:14:15 1999 From rem-conf-request@es.net Sun Apr 18 18:14:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Z2Xo-0000lr-00; Sun, 18 Apr 1999 18:08:16 -0700 Received: from badlands.nodak.edu [134.129.111.66] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10Z2Xm-0000kx-00; Sun, 18 Apr 1999 18:08:14 -0700 Received: from lily (lily.ee.ndsu.NoDak.edu [134.129.123.95]) by badlands.NoDak.edu (8.8.8/8.8.8) with SMTP id TAA203880; Sun, 18 Apr 1999 19:24:11 -0500 Message-Id: <3.0.3.32.19990418192619.006c681c@badlands.nodak.edu> X-Sender: msyed@badlands.nodak.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 18 Apr 1999 19:26:19 -0500 To: "ISIMADE7@Baden-Baden.Germany":; From: Mahbubur Syed Subject: ISIMADE'99 - Final Call Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_924499579==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_924499579==_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Colleague: Attached is the final call for the ISIMADE'99. With your active research in this field we expect that this international event will of interest to you. Please let me know if you are intending to contribute. I would highly appreciate if you also circulate it to your network. Regards. Syed Mahbubur Rahman ******** CALL FOR PAPERS *********** INTERNATIONAL SYMPOSIUM ON INTELLIGENT MULTIMEDIA AND DISTANCE EDUCATION In Conjunction with The 11th International Conference on Systems Research, Informatics and Cybernetics 2-7 August 1999 in Baden-Baden, Germany=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D More Details at URL:=20 http://venus.ee.ndsu.nodak.edu/ee/research/conferences/isimade/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Symposium Co-Chairs Dr. Mahbubur Rahman Syed, North Dakota State University, USA Dr. Orlando R. Baiocchi, North Dakota State University, USA Conference Chair Dr. G. E. Lasker I.I.A.S, Scool of Computer Science,=20 University of Windsor, canada =3D=3D=3D=3D=3D=3D=3D IMPORTANT DATES =3D=3D=3D=3D=3D=3D Extended abstract/full paper to symposium chair 25 April 1999 Notification of acceptance 12 May 1999 Receipt of camera-ready papers by the conference chair 1 June 1999 =3D=3D=3D=3D=3D=3D MAIN TOPICS =3D=3D=3D=3D=3D=3D=3D STREAMS:=20 MULTIMEDIA stream and=20 DISTANCE EDUCATION stream. Topics include, but not limited to, following. In Multimedia Stream: - Internet Applications - Applications in visualization, human computer interactions=20 - Applications in virtual environments - Industrial, medical and other applications - Multimedia in electronic commerce applications - Video, audio & image processing and retrieval - Vision and Image Processing - Image data structures and databases - video, audio and image compression techniques - Neural network and AI applications - Next generation applications - Multimedia communications and databases - Multimedia standards - Intelligent multimedia - Document image understanding - Animation - Tools for multimedia production and services - Networked Multimedia - Digital Signal Processing - Distributed Intelligent Systems - Multimedia and Human Computer Interaction - Integration of MM Information - Interactive MM - Hypermedia - Representation of MM Information - Integration of Graphics & Vision - Synchronization of MM Information - MM and Virtual Reality - Education and Applications of MM - Cooperative Information Systems In Distance Education (DE) Stream: - DE delivery, experience and tools development at secondary schools,=20 universities, business and industries and in all academic areas such as computer science, arts, engineering, business, medicine etc. - DE, the Internet and Internet-based visualization - Using computer graphics; visualization for education; video- and=20 Multimedia-based Learning - Cognitive aspects of visual teaching and learning - New Educational paradigms such as interactive classrooms, tele-immersion, networked tele-collaboration and WebTV etc. - Internet-based visualization - Hardware and software tools for educational applications - Instructional Management, student assessment, student support services - Virtual Education environment; Virtual university - concepts and futures - Needs Assessments and Perspectives including National Policies and Regional Programs - Organizational Models of Distance Education Institutions and case studies - Open learning and Flexible learning =3D=3D=3D=3D=3D=3D SUBMISSIONS =3D=3D=3D=3D=3D=3D=3D Submit electronic version (Word, postscript or rtf format) of the original=20 research work, not submitted elsewhere, as an extended abstract (limited to 4 pages) or full paper (not exceeding 15 double-spaced pages) to the=20 following email address: msyed@badlands.nodak.edu Alternatively, submit three copies in hard copy form to the symposium Co-chair at the following address. Dr. Mahbubur Rahman Syed Electrical Engineering Department, EERoom 101 North Dakota State University Fargo, ND 58105, USA Email: msyed@badlands.nodak.edu syed.rahman@infotech.monash.edu.au Phone: (701) 231 7689=20 Fax: (701) 231 8677 A cover sheet should include address, phone/fax numbers, email address of the=20 corresponding author. All papers must be in English. All submitted papers will be refereed.=20 Authors should indicate, at the time of submission, their preferences to=20 present their papers either in the oral or poster sessions as detailed below. SESSIONS: There will be oral sessions and poster sessions for presentation of papers in=20 the symposium. Authors should indicate their preferred mode of presentation at the time of submission of their papers. The paper review and acceptance process will be same for both type of presentation options and all accepted=20 papers will be published in the proceedings. At least one of the authors must=20 present their paper in the accepted presentation mode. However, poster=20 session authors may arrange for their papers to be presented by a symposium=20 attendee. Authors of accepted papers for the poster presentation must submit=20 their posters along with the camera-ready papers to the conference chair.=20 The authors who can not attend the symposium due to special circumstances=20 must mention at the time of submission and may be considered for poster=20 presentations only. =3D=3D=3D=3D=3D=3D INTERNATIONAL PROGRAM COMMITTEE =3D=3D=3D=3D=3D=3D=3D Mohammad S. Alam, Purdue University, USA=20 M. Atiquzzaman, University of Dayton, USA Orlando R. Baiocchi, North Dakota State University, USA Bob Bignall, Monash University, Australia Robert Breaux, Naval Air Warfare Center, USA Daniel Cohen-Or, Tel Aviv University, Israel Thomas Ertl, Universitaet Erlangen, Germany Arif Ghafoor, Purdue University, USA Craig Gotsman, Israel Institute of Technology, Israel A. Gunasekaran, University of Massachusetts, USA Werner Hansmann, University of Hamberg, Germany David Hutchison, Lancaster University, UK Wolfgang Herzner, Austrian Research Centre Seibersdorf, Austria Joaquim A. Jorge, Instituto Superior Technico, Portugal Mohammad Karim, The University of Tennessee, USA George E. Lasker, University of Windsor, Canada Ales Leonardis, University of Ljubljana, Slovenia Peiya Liu, Siemens, USA Mark T. Maybury, MITRE, USA Masoud Mohammadian, University of Canberra, Australia Kendall E. Nygard, North Dakota State University, USA Alan P. Parkes, Lancaster University, UK William Perrizo, North Dakota State University, USA=20 Mohammed Quaddus, Curtin Univ of Technology, Australia Laurent Romary, Laboratoire Loria, France Ruhul Sarker, UNSW, Australia Henry Selvaraj, University of Nevada, Las Vegas, USA Timothy K Shih, Tamkang University, Taiwan Mahbubur R Syed, North Dakota State University, USA Daniel Tan, Nanyang Technological University, Singapore Jos=E9 Carlos Teixeira, Universidade de Coimbra, Portugal Michalis Vazirgiannis, Athens University, Greece Benjamin Wah, The Chinese Univ. of HongKong Marcel Worring, University of Amsterdam, The Netherlands =3D=3D=3D=3D=3D=3D STEERING/ORGANIZING COMMITTEE =3D=3D=3D=3D=3D=3D=3D Orlando R. Baiocchi, North Dakota State University, USA Khan Iftekharuddin, North Dakota State University, USA Paul Juell, North Dakota State University, USA Nancy Olson, North Dakota State University, USA Mahbubur R Syed, North Dakota State University, USA Val G. Tareski, North Dakota State University, USA =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 --=====================_924499579==_ Content-Type: application/pdf; name="isimade99.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="isimade99.pdf" JVBERi0xLjINCiXi48/TDQoxIDAgb2JqDQo8PA0KL1R5cGUgL1hPYmplY3QNCi9TdWJ0eXBlIC9J bWFnZQ0KL05hbWUgL0ltMQ0KL1dpZHRoIDYwMw0KL0hlaWdodCAxNzUNCi9CaXRzUGVyQ29tcG9u ZW50IDgNCi9Db2xvclNwYWNlIDIgMCBSDQovTGVuZ3RoIDYxODMNCi9GaWx0ZXIgL0ZsYXRlRGVj b2RlDQo+Pg0Kc3RyZWFtDQpIieyXbXqrOAyFn8zqsqWErbGPZgkzv7IETwPY1pGOjA2kaVKrMzeA rQ9LL7IJoUuXLl26dOnSpUuXLl26dHk7uU7y6ijeQHqW2mTBqmdtXa7Tf11qJb6Kn8jW8Wv6wCQ9 TzJaH5i2ztZrpaPVYvFog28g1yjiAY7mWcvofHkVmulptoQW8zQ1KL1dheEgDckAIYB84pO/MHmT Lr4v0gjOFqnQhjGUj3wBV0WjpfOaZ+FkJCteRRXHpEAqmKs4TVc3+YMAMBQ51Xpu1jXejWkTKzUM yn9OqtFKP+kaNARa7L1PV/pC2/HQUlW84q2JZK8uvlIhKRYNSxua1D/Jlnkgsci7UhrK15QFU166 AZJHrWh5U2vQqtG1wXW0GiU37XQFo1c5wlKHl0W0im2rAq1UYfQcI4T6qtrW65LAryAsVnRh89PZ EvfL4DIU0m8BLWGCoJUKAxVK3Fahtegwzyao3GcadXXgcFtEK7roaM2iEmjZwuIX0ZoVKFppmqpH HVpxMICrNTz26NrM6PZEjNjV5vdytRAfKBotyIJMzgKG2U/y0ThsRwsbGaCV7wkeQd6i6i5dswwz OytFTTczKql/QjQINg1XM3zVz2VTEIkVFkJOudu1smG/84Rs+AqXganu0lWJCXa2UGIu4mIxiL8j DlpYnuakoEo1WiVbbNpqZHt09aS/RsZuMWiZfWEnWvYw80ZohY7WdpGngfmesLXBqrIY7eABR1wF t9gJzM1obdNV0/7cfrZfVN6PQUvp4EFd+rRHMhKeiYiHfqiusVI3ucuvlE0b7x5323W7dOnSpUuX Ll26dOnCZBiGn/P1Y57A6w+usIuQ4ePZ+tEVdpHy6Wj96ApXZY7l8e90JbFfLlW0cer8f/wnpH+W /5O1eEHGs+X4utl5YD/gcAp3MJbA/DAMZLoKnqVAJof4g2UQSyZbGJ8ejH5kFDkY4SwZMvnLS9NB mfX5no4SREvFK3/kU4nWoiLDH4aUQIrWIHViZhwElf1BDsX5MmqC1gDxCCuDNmiNBRWE+TGhbENr gKDIyqQz6Rzzp9AitZFj3NNhotESJNWgha+uc+/NhxIOasCxr+qko/bKm7L4+NcNZvpfxQXzXC26 LD8DBC2+aqgCNSLzl/8t1oLOMYXeLQYtPVSBlq0C7T5mHGof+FxjX5glERbRSggOxHi+pV0rPZFa qinoyX4GSHV510vBsAkmfwxSvQypRD0dJhot4aAWLdt0QxmtOI6pcef7G6JMO7eQo85opb3DGBSj YC3PG8DfcWhJW0ivXEIRreVqrTbstVeeDhKNFsaJgXvJ0uHT3JH5lWiBPV0bFTVFS2QzjdFgxGhW pJoME450HVqlLBUNYYWsJc+Z7+kwiWiZw1yMQAQi1jjMR6NBnISHQT4Xz0J84+y4TY2eZ+2LigcT tbIgHwkEmHGSgqAfkp9BBoF+WbZkfNItrpisDCIZ9AJlMVUBVG3UM5rDgyRlPdXK1mgCTL0+kM3F QhgsSeqBvpUxmHnGfkAzKVyRlUFPwa4SkkVtPKEOxvI/g/U3lELLFvRqdLpUgZlDsjCDlmhPaYzU Jj1zPR0lCS0ykl0qtFB5zfj6cC5yk36lAMZNxh3NNQ3nvsbQNmc6f4d7ahfRj33nql22olWYA29k ge6dMnDzVWi17hNltOpgrnbo5q8WrSfiVY9WPuJhv19zUIdW8Ap4VNvi4NYpNoVQQquu4lvQ0vmr svBctBrkVwTRpUuXLl26dOnSpUuXPyiXy+XVIXT5TLmEjlaXark8WtHUjkRPuizXl0seWf5Jjy/w eBqITy9EczE8qwcxy8zp8imyQBGxCYkfNZRu8C7fZPDYsPQFlvScLh8jBq3ld+onoR6tUIXWpaP1 d8RDK7ShJbdLD628RXa0/oKkTUqjBYBcOFqXdbQuGq1g0bp0tD5RKADTLxzG8zEJjt5p90yz84ne GraH/IW2TtYniqlqPmu129qk0Ln6ULGFvfgFX6GggZTFSb1Cl3eTeU9iDzegVT3HfDZ26dKlS5cu Xbp06dKlS5cuXQ6S0yKvjqPLh8kpy6tD6fJRcjp1tro8RRJPna0uz5KOVpcokYXERIbjJMfkQ0/t BGgJrZJxFUTJqNFWPj03yk9F7BU+zIjwx7yKUXSg3K8uQt9qt6pUdRWyw/M9CddLtRGaZ3CMEasE yF8IBbR84yYIYlT7xtBKaFl1Zk7EbqsVyivAdega2xSbcIz7lUXoW+bWXW3BkE5CvlWzcU2b0BK+ pFn8kbeFhbjGMQjiwxgFbcc6M+Cb049tscoFd9WK0Xj5LS2CEuK4XbsP/rCuvp19AFr4qxdsb22C VoxjECdiTfx6sbrr5UFoc9pLKSSnXZdqDLokam+RTniqHK5bHZ+XzBNE46XaLcUetLQqiVx5JFpu YaxR0hld2lfQQicmRuct4XnRPqw1tVJWBpjjLcpfHLNl3TqrZQsgdp1fv4BOQMW5HBIfLTqsV+5k W9VrbT1+9lfQokvmMa3k1lqzd77hLWgxb/5jvyLlCvFfMdmrTSGoElpJrGntmmt5xlUQp1M4Gq0c hIkRfnkRT24s1pq9O5m5KSRtkaDmoyXLQdyqB6sLYMv9NLROp+UDxQt/LfvkeQ7CxKiKq4qlnvqV QTW4Y7rJDVogz3Vq1VzfrbVeXABbbkfLsd6KVs4sy85haMnSMb2daMFzWhG+ALbcH0OL2PRccy3P OAZxegJa+dYWlQbh5MevjK2xo6tw0O7WFqe0rNssLD5/AWy5P44WeZxd5xfTarmQQBCnI9BiCeEx CjckSV4lxD1aC9YI6tI1W/f+4vSoMpaFxccWgHZLqfYLqFYlhYVQMr5+S567xmUQudBr6yHZh7ag 0tkWI+aFmTSxNKLl5pcWorgm6SmLV1eWzFPO4Ur1i1Eygbk5tnzJQ2au9bR86xqXQaSpK2gpQzqv 3K0Xo42VVGtlgQ1osTBXDPvDpIoObF4yPbv50nPrLN9FK+Sp1I+PVtK0vsvGj0Yr5EHjSGfDmWaK Q1ZArNkay+Xq8khVG2XQD5hfVkUW/okns2QX4/RmYz6sQO5Uw4MbnI9qaEBldsW4DDRsRov0ah2E idGklReHrYCvOOBdyY/Nr5OrPI5x2VCDFojPJNPYtQFJtEhINJK1oAoDOtJtotSXVSzXrnFbqyOc 7xQXrXLej42iYGybn63R3YU8bNyZOAPLY1etTpT68o6Ya0frWOc7Ba2dUH4qioLbbX6OiG4nWhtD OAitfWk7prjraHE/74HWnih93WeipYw3onU/vQlabIacut87dVtCaxzHWotEuzkod8yfv788Fi12 48X6DmjxGVJ1v3fidg2tB101eB2Yoy5vJqOQJrWv+1erUpd3kHONrBl5kPFNSPprIiXqdrpeL6nW +6E4BKwZrfsX/rXgFbU7XI2iitRaPH9+FRgF81XKtZtV3AxV96rMUdT7ZLi8krQCQevmjbTZKXng 4tsdV2XqJnW5m0R1sAa4fk3nWstiW6ILJLgTmgN0R+qNrEQsmSg7iArnr/Pt+3/5d0t/iY+VpWqB 3vXCzhW2q5Z5YKOldK/MqLBQba/SEiMmNhP6dOZi/lfi5YY2LlzJU1JkTNCxslIrGztXK43PlWLB G+lqhasxND2U+0tJfyIGa30bp7FR9BrNxfwX6XLjGjVX9G9LpbFzVSu10liSsNtCmZkVus5lFsue nIDcY4samXefr5FbktW/Yf3HBc1lL1OjYod7WNfmYQVjiagdXWtKw6ZdcZ/P46VIjOGgBa70XGFS Zit2F+ggZzEiCRhNPFD8eR4h6xzZJPvZclaarqCsyvgTyUK2qjtf6na/ha27YUI2i7uhwM4i4MAE 2G9ucYY2Ol+MtsrfFZ4GR2DgJm05ZNkda5RjZlSfyh9U8xxBNAfvh5CHtj3uF7IlDqfLiTauKRJG Jo+x+vK9l8Uede3iHmbYEg9GMRe6lmZrtWuNPlmPM/jNnpTEN18an1evuJri1Gs/smsptupPXK9g yz3ERJm5SruBrIt9a2Zy7MwvKLZlC2gAa6YbSLJiS5OMIqeMLNtDZGQkNkGVGB/ZocF8Hxzctd6L rZW1P7jC3UC8kxquXB81E+pg+wbuYdJYVhIdJO6HZ70GQZ13FNTr/Q/Joh1LdEoxwgAm57hju9ZG tl5zlqdsjWYcTrKCQYg151fNHO+ywI99R1UQ6iRsmW5DupbI9tK3EC1p2a52tD6ArPSWAFe36EVH qbhK367Om7u7Xm/HlkTL5hnoGs2RdrSzRpxgdw2Dlq3a3ANzB8lomRjHTOgdDRt64BQIIzf5hpBv RrLvWrJShMDXrvqO3EOt1qvZkv5HzGnMd+48CS7FljjPjjBhVPuqqvADAdIQ4NRzm/dQG6P4RoSY 5vsiWWr0Qe/0cfuf+iZJtI3qg9ZmEus4mft3d3XfiC12smUx2d6lopUd5kZn3NO4PuezQ7HpCPLU cwa0VHyxbSFYrPYAHu1L0G/gS9EUSWeSVfH7RdyLll+rKq0d7kOrQhtbd6jx/WbJyR2G2MvjNxx3 oZqV4pen7BlnFiP9RqQrOSNZSx4yPbn3PXqNfa90jWrIut/v+uOnWfZ9Jb66b3k7ItAlziEjNK6l w9yovXlcn2HwoG+guMsTXPpCPNMYz+qL80zO+zODSNZEnjxhjWA/jth9Pk0qvJ9Hys6T/Pa4wgad TWzJHnK7I1tkx8sCp7GbGPfJmjIjaV46jhiF2OwXp1mHmLUM43fKGd6HEUaWdwsPW08ka0xi19F+ 2noa89xtNVv5W0fRJTfFUVZhWQ1wctZ9C78hLVlTDOhPk5f+HjsiFexZZ9XazJdtSoEeJeyRHB5W QHHWu090vfC0tUHst5McFFzND9KTXG38YhP7yqypdiaskf0SUGClGHK3G2GK2hE1JbTrarR4BuLo +ab+8ttEM3hU/UYTl37CPWGnu8Pb97Nty2TfsiXPn/prCms94reU3KEW9a/7F5xdTNfCzUZWTnYt hy1xYiJcLWOy7f3zLZSNJZrHsO5ZqkLP2Q//Z79qs5xnQeg5Wd27aPbRLiH9U5cwbxujAsJV0895 RnI600ZAlOsFyepG9GNMVTFd+FJsUb1XuruR6OEcE1lNXcY0u+g+nk70H55PNkpGPJCxVDW7Q2sB 2DCQZ56+pyNLe9V13Z7LYLogTt+bSyI6C1RHo/QleqqO+SRpK3dOvG8RFXP4/lXvOHrWUENr8f3f B8fuOmWMDudRIaS0I3gvTKYjuUPf08mTEUsLi3D11dqNcdwl64h6Kgfa2xt6Vm81EVrIh4Os7c5z NI1+tw77OueMkbyNHYzpKSvRfG8YQCy2sVMyudq7Q+Ra3L5XtGVjaDXfGiflBh9Xo8laJOZaUxO9 vTmYRnAPRKzlsjfRl2KrRx9i6z52z1DInUvK5RI5YW94QsxyzFIxCJQ012i3fd/Howqz0d7vNivn JcpFMMWbK2KxDznke8TcPs5GZeptJNfUbe7t1/0b8YWLHSwBGAqqGqKdh/WidGgfq4i4wvXoI84O Clq381xyeM8ELbvcNHmOdoPb2zVpJGQVaGXb04685J3bsG6KismeS1oYFu8aGlp55uJTTF3QHMfX PKcHLe6mViCQC8BaxnlPHdoQb5jyc8DGjriBLXxnsrAlkJIysWOipJoy40jWWopKsirjYmRHyBqE zVIqHnGTGG5Gzv3VGhxoKZ9BoK7MzOdcHWgJNwa0QCb8+oIqiez+P1wR4fzOPSQPG2MCKYxXEsvE /ZaVJbFd4rKosRoZ2bulgpBbGch/BWtRrkUZWxmZLmtl1Ja40wiV6pcjjDhcfNbSE0gFyDE+B2B2 eLAi/oyblKkBC9XKNbKOslbhp8DRIeoJ7Twk9CU+NHcEDjrmlSSkQkikxfxX0MrxLAxB+/jehwls tnotHrQFLXTGB1jL7dHey1pD2DJvIqifdFjrlLmmWHHW2qtXqmGsiw/qyEsEFdQt+70geyWWQwat Ekmak8+Q4lnTd+I+9MzJj89aMgKtAJH1FNZ6N7b6u60msixffAOpYq0kIWePMwgxnZq14pSKO/ZX KvP8rspzKupdDS3OWno1y7JIvuxjLfalghY84S4DtPL3uTtiP7ZMZDU6AgWtirWqHEkGYthyWEt3 POmd8sqjXFhIe9fXYK3kn8oQi6lU1IdYy2D8riy1qs4nKyK61wItM9p6fwS0EjfVrCV7rYQjymhD rKV6rRhH9rqKFe3ThXQDKJ41GmrWooKJhY9KhG092BFo9SPk17BWZ7dl3Q7rc1Bhy2It0TvRafFZ a2VsIG6IjHoq1lrKjSFjIiTlZBgWWcMqNOzjG1KWgr0ErROPdr+Vxn/bn/E2HtdDH3lfzVq3DGK8 6AhHdkDvZs7nGrG137Qiy+wnP3ZPC8VLXEi9lOAr9k/aBGazY3gPUiBL17BsmY7BwuKS2CvRr1aX VrwIepVBC5xaO3e4i0cZ+QC0Wlxk6dixAtZKiU2VsOrRF9WBBaLyK2noTvqepZX/YEO5P4/CcBUE azH7jD4yImagSSNL3aUZzgKPYAuTgvR5uB62erQPs1YHtro6rU1RabBNT3k66YyVdzsPpLekOual QKtwEJ2YDYfWKWc+G5Q4+bwM4xlZAvcFW3Jqs0urnclZN2DtTFcUjnbxX85aHZ18X6dleFKbzvKU v2W9JfNAelvpFmgVrJDuq4QN77TYlzzDEm+AtHvb/1F6n+JI49uEBXN3rRpaqihy2aAVMtNlhUHW YsO4kj7KWj/jJv78PSsDkaqVys2lgjfbo/lWohTPSOL3EnukTSS0cNcM96ORy7ZQAwGGV4C8gf7/ E6w1zMd+pMqTglbOuINVhC0XWiom9nuJ3dcmS6GWpYGPOgryR4fzRabVENYHkP4Ya/0MW9SCsWVm 3A70AdYibyaOUgNgcvf4L6Gcm6AaWXItA8jy4I6EzN0buiH2I12fuw8IrvUWa3lxSl219xlbtb81 eoTYCja0xK6TNztDFs4HvtWI0UPQsrAzFBE69wiTn4HW6Dn2T4DU1dBKOfexesPGxcNWMKGl+gl/ 9nJlQ7mqdgKMvom1BnD3faw11LnCEzCK0VrP7uzAnKIiDls01gq7niPJIjvPCCEQPZCZvoG1YLeF uw/tCGm62Gog2dzTlv4BZNEQsvIobeLvieEBV8SBmgeZ6RtYaxBbCFpIsw8FjlY3U8Zn7dXPetRc p8EfG6j6M0fVrGnAnbfFlP4t8HGOfYpQOLu7ijtb7Qhkx2MtfCNq4dnx2qtfurwxZJ02rhrMHHX5 BifNmIZWZ7Rp+SYBteBpFbGXj0y9QdbyQ6x3XGBkf851iQO94jBrdWOrjQ8y7ap4PwcthIlWpQC6 PRXRIPnHsdVdD8ngK9MeImuUtazzZLKPqHf2JB5ev4W1ULeFa4VqYYcrYuMktvfG8gpICyJkf4xO 7RnIAqwl11wawJ45bK/wRtUlP+MmToCriAXf2kiM9a6on18MzSG09NZD+7HoAdv1QgtZEOV+l2r9 C+xCzvUewfrxXgHdFsAWjayon1+GmKjdgTc8i+di1p0GIodZy7SgXBWJ1C3BKYbZsPIKqlCn/Axb +PGNYStKEz8tbDlLVhyK8YIi16otZNk5bHHdaBfvWdx39Kx8Xxq4ioar8jqwJ55cnyd0PYmH2NDp ih7yvRCaQVrKYPAsUNdVtCKQlo5pY/1oRseLv5ib1no93z6n6+V6P74jvpN2tc4+L68SlCG69O6s 8gJQh1dM525dhGaoKZ7L1c1iC1k+6t3ZUZBMuvzuVtdLPh0DZ/g9ArEFz3sftuoMoQVX2p2sNeSz oArlkbIeZxT2fZi1XpFpysylc3X5NLIalQVhq6sijiFrAFvUpXU1mPBy7WGHjQ8ICrQ34nxNqhNz Vfv8cWShbssY7eQm8u0bK+7uobjnc6Meyj6ma88HS5Pv57WstU2xMZZk1C8A1rWJLb/jIt9HGhvq tEwLt+5Q2Uu0j0eY5plS1vPKuQ8R6hsEY8vvuFZQ9yKPWJZt1uJnz9+mL9xIS8rOfHWYL5Jmf0Nm J3xmehFDnJMjtIweuAWtXwKZXqG/jKyefoh0XVyvIvV0qTiZapr+dwDTL9So618m4cn+6KrYxdqH DRZJTyPkzyGmW+K5/bPb008tf5N5HhF6dQf/VHk2aU15odxYa57EKa8Q+i1d1pTfJpOypkyZMmXK lClTpkyZMmXKlClTpkyZMmXKlClTpkyZMmXKFC1hfubnNZ//BwAKasJaDQplbmRzdHJlYW0NCmVu ZG9iag0KNCAwIG9iag0KPDwNCi9MZW5ndGggNDgzNQ0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+ DQpzdHJlYW0NCkiJ5Fdbc9tWDn73jP8Dnrpkx2LIw3v65FhK150o6VrK7oPTB5qkJTY0qfLi1Pn1 C+AcUpR1sdtpKu9sPKEOz43AB+ADYIGFf9Xi9OTVjzMLFvXpiWXDyBLg4X8/FFClpye3pyem4ZoC hk86hKMggOHz6kechZ/AhF9xxhfwBSwTpnD9iwkJXg4Z4NPxDc8Bz7ENxwERuoYtYCQCQ33vzfen J7+dnrheaAR+GOJlJspkW4YIwMIzAfi+bYT4D+I7FP3yzoJxeXryL5IodPDA4Ely4iEUxXOEIRxw fcswA7zQ6753i997M8eL3gpEY35LEhqmw9+VIyvwjQAlRhkFzO9IR3MDBxNH8/j0ZERDG+ZfTk+0 y9nl9Hw8+UcYvoaL83fv4O2HK/j5/OfJ1Uyf/3p6Mpk/Ia9gYDp5HWMtLULr2jB8qmPCYTV9shLi NOJnd+oZ6womf/3ZjR1u4BjBgRueWl9LgD9yXViGJR5vkJP7Lzi0zsjx+hMq7BFBbdj7iafWTSMI KRzWT2kb8ExhOGB7juHtdL8tp7MC9tcgMGxPep2MP/zrvM5ir7vWZg93+sjXVvrI1co6a/kNLsrR xTLKKn1ka7X+y/ynzun2SOgGLmnSiSgoSjsJbd+nSamEMP3naOAIa7/42kVZ3KZVWsQpSCnXQbFL PiWAkpEl2BBQRrDTRbDVi8Ijx+LDvjDcQQRLHBlDk4P2WhtXBkyj5U1701ZwFS3vdMvXogJmD7pl aWkiYRwhGVm+gyAYlm+HMB9vsYBQF07yNG6qLI5ymBQL3bK1jOxRpGmVyXcY676W6qa2iqoGvxfy S9GoT5F3hdbGp0brbw0/Be9LtLWnNWT9JYwjfeRon/VQK/WRkLM8BbP1mEcpz34sMnq510M5wXfV NOJ53vmAi2fwcXYuhbNCwzIDH4RhO34gYRjAyWh+qPKoSEq4MuBNlJVxvMzY1Gg+00Nr/L9jKNDH 7b0QSo/8MS2rBTsgSQETeBfVn/m96h3SDfwtLK01lpa6bhYvyzKH8hbpAYEKtFXbpBXM4oxCscfL tczwOaZBhe/JAGlVZ80DmwKv/k9WJHVZncFFVERJ9DT3cMoRmGWDP5WghYtHwcV7ME1vcM1GknbX 8ntK/qnuoRHJoXyt0BHbebmicfwMwmShLczb3iBLO86z0rQrmBf35riD6wwWrx/IcftveGq9k4DN 0edI3Ptog+kRm+6/4NA6qSDXD6qwVwS1Ye8nnlo/nC4w9VLSwNLU30oXu+NgGmUFzCm80X/iGrIi ztskPYObtoGibCDPmJayJk2gKV9L73o17zxalrkhYJnrgYPCIyQ7Kk2V76cf380vp5Px5TnyQWhr s/nV5HzaX9qptZaa+MH0OGcK17Y7miGO/iQ8nwn51VuvO2c4tMnkbRqo1R4sw+RVqb2iBmebaS6L JtUDrSro2VBsRThYrfIsxl8aN1lZ1I+F7kXFHOuI7Zzy18jrKua3/c6C57owlXQhShcq6bCOQssi xwnkCKqjfK0lEqYdefZ1sPcMdGxTtCVWX8Lm2ULqZioitdeJx+4TT0dEMSYYy9TQSVyq43DY8rOh mg4JOqPfYjClW1oVxTzmNXle7jgqqBtx8TxUK91FrWytZVQhZewQ5I0NZcHA9ovNUbW08GCn5CVK VyQtqdWQpBmrcQa9vEmvfo7KAPtGAmWzpMVql5dc8+5t4I6iceetru10dNfmDRKaoIrE1xIucCJl VZrJdbkSEyTkqWWR0ViGCI1KOsM39NdUMRdxO9BYw/6icPG6KPZ9hcu/swQD09TKMzQyxXCSlfAd VWpAcDkaz3LJyvsAVhVWIGVMLzxTIy/S/0x3NFXbImbqIEW3luxDqOsGq5TCqcro556p1kWDHBGh jvIURJ16ZSFBwlDYDc4T2LwUjqPw7zl/QZRFYQ0Jeyc9gJlB0RhnD3JeJjyaod1MiYoX1gdvIrUk txzVyYVrbTu53nkmO/pha7IdKUtpvExJTiMDb5m23Jk3r7WGd/I1yyL7rVUHX4obvFd2Ypv2XF/Q VPOF0mBJC5/JP4bW5gxJLgQviNkOqPc7KUC+C72rFzKNub3UL0kVW6Vr++nktSMvtTJv0TLrABE3 irhnLw13ieplhbHdtQ77lK8bVi2hZ5VsSWn5hhPirdiGBcLxBmL+GQEtBxXeFFD0JfFGA+FpeZ4t EDcaFlToNlRXcXmMaY11MXkx4VI42gGv9/dHy1i6kmR6pvx18dowQT5OF22RdGHE6ULSQ3asPNf5 y7luBdLhpdd0kfBsqf7SBhPTkNd1THNqlcoyr9H2cKtbDDjmWHIPQZjbyj0I4IDcwyb3CKiuKJM2 Vg2oLElpvqAdXVhLb99q3BwFS51W99h2eVqcbge0+Ma22Q6V9xQAmGUIhOqzipbkDwfKN/ar0bpK VVjKWMkWWRPlUGcLNAHWqzms6LeiCqGkEYJcZ7x2pGjYRnyc1Vhi37RNjyj2Pnv4qn4gJ6x5la1w 1KxuGoEdPEqFqk0lnuLmtStOlm3PVAUtAtFZ2dPZitRfd7DbMTNkEoYHc0vU9YW7WORbh46zpuqN NEOeZVE96jAVMDGUTCownaJlB/zCjNJteinuqHIlgouURFyQ3SsffMEkcK3980G3Qo2jPdUZW4Q5 Tej9D8j27XzjijxjVaXcnXicRzhLNP8DTrKnU+U45rDl2mOjbCdlAlXYdwurJVfx3LJ8x43cPS1n aC6ao98XpOEMqRZ1JImXpEFZZF8HPUinIbMXP6TZAklqdKInvONZ7slaXVbqZAgTDYC01bQ0lUOV qmYlz5qHvzt+dphjQnVWuNkXouC720NUTJlnOn0xDnVBTlSuNjvc+75qP+g9QDqxQ3JFr8ssy1v6 CkB00qKgJuoooFqgdCEIx3Btyx6oikXH5Wx+/v5igl8LbW0y/nhxPr/88F6+ftLGk0+6HM/mV5Pz 6evHKPJH+AM9nsKw+2T9LWoN13EHLdEEMQDuc/I1iIQbo3SmY4VBM7/TUo95poArun4qHVQoDXYA soTna/tL83K17riY8rpCH22j6pVHpYpld0Ync9FBrnaKhM5ULCFblMmFGw9fitwWA2WYFJssVZzJ G25ani26Sfb1XhzUgsdZkfA+rCvlRpZy/r3ySLtL+iQwixmhYsgACT8ho4wuZyDKOd9zWRrFkdyR 3lHHxNtiJA2IqjSqoW55MV6qkzXEJQ9594qHcktDJ9NKClvHfFGKF8lvxukZ9UNKrYo311TBnz3S w+mLF1/pkdINlrbghkqO07QavC3wakTshl9aftZcqw4O1LXchGI7KJaExZJb4uFGXIK04ekjVT+9 Jc2ulx1PCC4JICMnrZHCZTGAnphevqeNNO2GAxzcO7rhl6hO1e57tp+yvvQXnvkaNf1YOsJRs7tp CK9jkI8qdIgQCi5S9vUj7v4i5ofN+qWlwxET0kahsEnrzEqbueyH3SSys4y819kTBXEU3joCqgwx 7LlKbKlglIlecIWZ0ERGW0Y30aDy5HnIaUjT1KsUGeJwzBJeKSxTZUl1+0L2vQGR4D1JjpQiC/y4 qYG33LLpaDEjlcgHUaUcmvS/xFddc+K4En3fqv0PqrovZgsc/Ik9T5cBZ2eqJiRFkt07NfNiQAmu Idhlm53Nv9/TLck2BEj2vuQhQVa3Wq1W6/TplGAIS7fGEqc4Hz2io6elMk3LtM47MrShHbkGw2bE vH4ye+k5niJsu6VmY5QviqCRrKBhSf9W2WOPkRYUj5CY9NdE85jhVZR4GTV2Wn3Jppj1yfPZ59ij pkoskSubnupGKJXoj3Inzznj6LNP5YBws6bk4gwbQIMylnWa1KR1tADn6YstzdQ/qYPLSfCjx/CK 2xJdOw36a8Bbtiio/cN5CGmszSal8QLWQouHmjQSCK3En9wcssYdDf8Q/FFja7Zhv08uhDriQ8c8 90/8QuERnYPgFomBG26m2O3mWFUvUsd/oEjSaY5p10w4Il1fWZUXkYaaYz3KOcJzEzwebI4lyzfr OAt/X6wPXrSqhjoTDO8MA1RHi/lB+S3p5rlHQ8Va/lf3hTGzW6kZ5o+Gi3V52QFrfLnyWDD3WgYu K0WRk8e1MPbpS1UeQ2HfOdaBE2mH/8jYVTqjCurLaieaiDTVk9bk2xfh2pN3bCJHfWuPKfdUX0Sd KlFrVhicjO5L0rQ09ETRz6JlP8w7D9jRQ2+fyKphKd/5FpzIsJuZThQOvsl8LhhvTNU9fQBL0Y1y YfqZTvfKC7ItzW44wTPNqrbm2vnqXk34Ilcg0jQ9pjmjzaV5kpQT5tUWnDx7FI0Poy8juePiGkei +5/6VsezR65wg8B2XBGMENoIfoV27IpS/vrLA8rMxzsKvmuC79uoidT2qhEtxX+fV9498UPAQaDA v7RHy26+Wbe7xRO1FVlVtej4qnteZLfe+bbvN84N7VFAqdD+18tc35wKyYRVrmN7YbNMK3gwH2oF /v8v5OwXy41jexpB5NvRORe0wsktXpOrazFvIrbjkG+FB07EV+OMcI+euhUW8m2Yd++Yh5I8UfVL MwJ/pP1a8q/cgGCWOTd62ZKn/pIlbo1n+Pu79SdxRp4piWataNRnWk3ygj557gGVtt/O8YoK+VtX yzLjqZqlrSn+LGtaKB56ZhPlaf29J3JjVpDD7brsMduC+gKHQG6Xa/GTnoES/wDFytVe1W5BAzaX 1bVkJ4XcVJL110QTStkH1cbT4xwNELFwFGlM0q9VB9Iwry25I/8mFie3qsHwLbkS6aKqy3SpK93A mKL3Hw1HxqBncPg7eidmiBkcU3eS848vivSREQ30lmJQEgo7gF5gAEAgLWQpvsMNcJmaHAFCSQkU YsiILYErX+WkvdjIAa2sinSJPfbN0m4Kwy8jk14qt4TnIiWHoe2EnFXWU/UsV/9dpKtNul1V9jZf pT9sudrZB5C9n54+YYavDZn81MH0Yh0FMSYHN7UstykwVm6eqRlQybV/fciAUkqx5LvlZMpwElOI Br5nx06g6o8Txi96jjbwHCix5jINJriCyeKZuKMKc057l3wziJEJkalZER6341NV8nznsK2zPpgi dhhRZzgCtjkxg6nCz05qBSa1pqUtbhFrcUU5Nk/XTyk6hqks0rJ+kqBf+YNI+MVmS6R/ssUzkLJE AeqLZPY7asgcRPg/ztDpi1le1msxTX/kdSpu67SW4h48gh53/dwXl2n5mENrquOHK9Pl26Pf/caI jmtoTxA5w6Av7vF4brHZ2ETIGeozB4oIDF9ygPP5EsZ2hLhFru1GXhOk1oGgkzIgPstct3QAEKaL a/6UNfV/zTfeAVP5QJEDkTFBJuazYWasmA5wUKSrFdEaxRG4tSuUBVaXF1B/oOeZYsO/ubnYKm6k WlHPWiC0tFRIxaxpK9pk3zKukMkCeBRePMTKbfW9zEulWahdV4273PEqpXSn+je9NEfO8DyH5VCm 2A2JT4aEpc1GvOUyJRNARrWhxkbX9nw/OnaxNV/sIBjZgY+bPIA8/Tq63KdeEykTNSEgnR5BienB Y3bBU4o5cDiVblaC/khSA2STYCkrwrCCagB91x1FgshKyEzNlGBrFAa9aV7i6QBUi7wC7IhKmq0q oGqxkWklMSnFTW/A3SKYoNFTgfAjOxq6sQ4EAIWVtpUg73hcCj6EGkuxol9J7LpG/QX42ga0tCUE bBR5Tiew3ywFjMB7grqUbopHkkY4HKPiDo+wqsWiEeCkhAqbrFrbwlg4XgZP2OXKmGFVxyjFPdIa Ui2338bpHMAyHvX/RTl9cEsIXcCCf4ZzqpZg0G1xPj+hjaxT4OUUsMcP723euiEB0b+moI7vE+c7 yTDPyjlKLD/DME9beE1uPOB7OE2SHdelaJ82cE7OoWP52SOcdEErnNziNfk+SXacJpF4FHA6OUPf 8JmWJQ/2ynCDTsn/iPDe4cE6VtIbWrNpMhXjj7dqZj6eqMHF5f2XL+JmfJPMhZq5BtkVt1+vbq5v P/ec0LrH95WYXA/oY4LC8WnM83M8ISfyLTcQ46IEJXfiOO40jL4fjDS4zK6VaV53CWc+G1vjjuB6 Jq4vxXgySW7U7Hg2SfBeh8FoZKE1uUqfmRk229z9RsbnySTh9TcwrBaSncn4KpmPB8pT10rG06/q mLfi41d91E84WoKjzS6TeYLNxKQ9m+96seWOXu762gMMYjv0W7Q4gIq76ChvcH0wBuFj6UFr2mmE vlmXO9AhiebBjWJrKhmI1QdqHf/ez798eJub/mjPzZB2fhuo+QH1eZ5vB+FxX6maGhKJjkNZGdou yFmnKdF0c13XxYeLi7/kdlfZUtog57uWnV9IeWEapItlvn2gwomqeZFV2VO6AqOhbdRZT2NbOGxb 2yO4cE6MSCnxGVQ4uf4Vsdpd5YuGlKh7DUruDTlTTi0/J4bzSnzG+dPbK/lJ+6+I/xkAheZi2g0K ZW5kc3RyZWFtDQplbmRvYmoNCjUgMCBvYmoNCjw8DQovUHJvY1NldCBbL1BERiAvVGV4dCAvSW1h Z2VDIC9JbWFnZUldDQovRm9udCA8PA0KL0YyIDYgMCBSDQovRjQgNyAwIFINCi9GNiA4IDAgUg0K L0Y4IDkgMCBSDQovRjEwIDEwIDAgUg0KL0YxMyAxMSAwIFINCi9UMiAxMiAwIFINCi9UNCAxMyAw IFINCi9UOCAxNCAwIFINCj4+DQovWE9iamVjdCA8PA0KL0ltMSAxIDAgUg0KPj4NCi9FeHRHU3Rh dGUgPDwNCi9HUzEgMTUgMCBSDQo+Pg0KL0NvbG9yU3BhY2UgPDwNCi9DUzEgMiAwIFINCj4+DQo+ Pg0KZW5kb2JqDQoyIDAgb2JqDQpbL0luZGV4ZWQgL0RldmljZVJHQiAyNTUgMTcgMCBSXQ0KZW5k b2JqDQoxNyAwIG9iag0KPDwNCi9GaWx0ZXIgL0FTQ0lJODVEZWNvZGUNCi9MZW5ndGggOTkyDQo+ Pg0Kc3RyZWFtDQohISEiTCEhJU5MSkZFUUNuLFU4biE3OjM4aTokYTluLjVUaCYubj1CK1JmcHJu LjdrUyY1X2otQC40X0huLjotPg0KJjxRQW1UXldNc24uPEQpJkNCblhpOiU8SW4vcWAjKzsiI2Ir UmdMLW4vdCFjK0FoUE1ALjU6WG4wIThOK0haKDgNClReWCkubjAjTzkrT0tVI2k6JWxZbjFYazMw RypfLStSaCc9bjFbLHMwTXE2bUAuNWpobjFdQ14wVGJjWFReWFk+DQpuMV9aSTBbVDtDaTomR2lu M0AhQzVTM0VNK1JoV01uM0I4LjVaJHI4QC42RiNuM0RObjVga0ojVF5ZNE5uM0ZlWQ0KNWddIWNp OicjJEo1Pzc4Ol1UdV0mRmBMPW41KGguOmRGTUg7Ii46aG41KyluOms4JTNPUlEpPm41LUBZOnIp UXMNCmQtc2xpbjUvV0Q/aV1cKCZGYSdNbjZkcz4/cE8zaDsiLmsjbjZnNSlAIkBgU09SUVlObjZp S2lAKTI4PmQtdEgkDQpuNmtiVER1ZkJIJkZhV11uOEwpTkUnV28zOyIvRjNuOE5AOUUuSUZzT1JS NF5uOFBXJEU1OnNeZC11IzRuOFJqcw0KSjpOMCMhLl1UTW46MU4uSi5WNCMrUmpuOG46M2RuSjVH YGNALjhcY246NiZZSjw5OE5UXltLOW46OD1ESkMqZTkNCmk6KTlkbjttWT5POl5vQytSa0lIbjtv cClPQVBHLkAuOTdzbjtyMWlPSEFzblReXCZJbjt0SFRPTzNLWWk6KWl0DQpuPVRkTlRGZ1VjK1Js JFhuPVcmOVRNWS1OQC45aC5uPVk9JFRUSlo5VF5cVlluPVtTZFRbPDIkaToqRS9uPztvXg0KWVJw PC4rUmxUaG4/PjFJWVlhaG5ALjpDPm4/QEg0WWBTQFlUXl0xaW4/Ql50WWdEbURpOip1PzBZa0tu Xl08bD4NCiZGZElYbkEkYUleZC5EKTsiMjgubkEnIzReanRwaU9SVSZZbkEpOXRecWZIVGQuImov bkErUF9jaUVSXiZGZSRoDQpuQmBsWWNwNypJOyIyaD5uQmMuRGQiKFc0T1JVVmluQmVFL2Qoby50 ZC4jRT9uQmdbT2k6LTZvITpcblhuREdHWQ0KaSVYWlk1aypdLm5ESV5EaSxKMkRKRk1LWW5ES3Uv aTM7Xy9fIXA6L25ETjZvaTosK19uRE5nKm5GLUdJbi4+KlkNCitSbmtTbkYvXjRuNS9XREAuPFop bkYxdHRuPCEvL1ReX0hUbkY0Nl9uQmdbb2k6LTcqfj4NCmVuZHN0cmVhbQ0KZW5kb2JqDQoxOSAw IG9iag0KPDwNCi9MZW5ndGggMzcxNw0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0N CkiJvFdLc9s4Er6rSv8BR3ErYsSHXkfZTuLYHsdjKTuH7B4gEjYxoQlFEO1xfv02ugG+LNnayu6U E5GCgH5+3f0hYAH8be/7vfeflgG71/1eELFhELIJ/J/OQ7YV/d5dv3eygi0fY9i8gm9B7I9iNoI/ egtm5nM6GflwYvXQ74388Sg0G/Bp5I/8Ebytkn5vaF5jtnrq974NPhc7sS34TqqC5+xmq+63/MEL 5gN2qvCJH3K3E8L79+rCGDFxRgSVEUHDiGjsz2IyAn80ylFlhNrN28wq/80LxgOVgcLhdIAfPGVL 3xvOBmyR0/I7/HZTbs2XtBTsayEfvdlA4IKWO/P7MyzQxq/LBdk5gij6wTgEn88qXVY0npE/PIjz oPwJZ81/Dl+tEYWVdUATU3ewF55n3HzFdVV09K/+YbR+MYt4PudFqtgtWXDCpUqSTNKZa4U7UE4G Qr+D9HigjD24hpaxJb3j59FRICtO1JqdyHv0F9Kc0yaKfsF19oa0Ral3lR9oTC55U/6tWovaBXaC 74KXf1UirvmjC3HOFhI3sD+8YWwXcYGiyuk0OxUF+bqtYdDx64wXUuSA1EwUQ7OrDjftX6HLwqo1 JqCfb/j72XxqbxhZj0XeVPqp0iEoopQ9BMZZmQrKXiPEiZGEp2Sev6H6lBc8bcWWXMgUIVOzD3Wg cy8cHEYqF5SNDw5+ZK2wQEWDRBV7C/znpuoF/iIt2PFAxumbUttfKU6Sf0rhtcAkBTXqMQGtenyZ F1oqzBmCKGksbZG4Om3AIMkKlSvSeFzGTcOa2oa18BG4n8xnCZWDyY4QshMyc2qTMccYTCgGBh1z 2zamiArY7Y0GWvMkK7XY2ZROjQ2Y0+mLYJliAcjBKZRbkHh2zgv9QNqPVX/O8cCadphQBFYl+lWp sGJbkFhmqvwTAy3YuaBTl0Z6qbPShHEK2RhhMqYD0l3uqJ6d+hUqNFrqXARoIYm74BtevPRcwYGc RNAJAjQ0xnNy5CdIsFEhQdS2puSM9CBNBbsVWlC2ksx2GLvBGMSWQtqw6FThkzQeEthGiRtrZ9js JFRnys4Ji9gDMqndmLjiRcIJsnUNvlU9l/tBeaH4D4xEKTFlzKL0QjUSbHP1SoYUW5Ybcl7SyXaq ZKJIxg39SkdtLlodEvFNY92hKGWXvArbQ50j0pCJt1FrbSkKobUQe0qkmYErGiKaXQJYQWqepzyz Y+9WPdej6Jf7B46dS9pwTgqWTx70BJGKFooXudDsSsC8pWYp9ZEk4wpdKNc5PmE+WC25wnNFexTf CInusStZ2o1SYBcVhd7ThQ0zC2aOmYWRY2YmPhMDyzAcQJML5xiFcGooVBhBD6MNz0byGl/Lxoln Oxxw52d80ulb7Jcf3Ig0v3/FpSUudQw7RBkxeVqVKdvHIOXR/A2mrSUuNbU5kvJciiIFJsU+EKG7 NnIJFTWfSWt5/3eKB3S5YDdkzA1BjHQI/b/pONSHkcNICje7acTOdDvDotXf6PPL5IuU/Y4FzNO0 tI6flrUZsnAajucGb0Ch2YmveEmzhOYKtBrqfm6i1kPuiq+pi3LqvbKeQVf0g+S086PlFonY3+pu y6zM2bKV8iZjvl5S3o7E9bkoajq7FDnSdtqN/efIyroWeDDlDnya/VM06mNfKzJejangrW8r6QWj wYPyIH2ZZ4yCDsMuzVhYwodZwh3m5R1bcXg8fKeImymHTCE2HQb2FG7zoxEiPINbsAOXdijYSsCV Jy8MrJTjOlK2LtcENHbLliYWIv2bysDeggjIrvddG+I2GzjWfwjmMuFvXUmW0srgG/JENJVfKP2v aBxAK6VrBrQBpZvapLkECtltsB2dKU8Fg3+nSmIhr2m/vV80IlhaW7qEY4wdKMl4LgFq/KclYHjQ ugoM2Q3dBWUDRuIbzjcueyJpOX4iChrIaC80FnubzZo3TyA2p5kEylKllDq0K5NzZWN7aV66HtWT BOkj5Jh0qGq9ar1WzJHVuUCb7TCgUUVudGy/FjZO7gqZajLy/ceYBWx11+8FsT+K2Qj+6C0aT/w4 ZtPJyJ+HbPVgamU8Cs0OfG7vqXqojoa25rGQljshtgC2919Mcd4Dqn/CN4DEgxdCFzAfcgd7nAkT Z0JQmYBvEeiGxzSa+JMZmYC/GtUHavhLlWbjpGK3lKYTLlWSZNKW1Nnya6cAR2wY+MEsBjlnJDGo ZMdW9qU3HmQwnD/f7cT3jG/LNJUeXODesWt4nMH/Jez46iElxm5FK10uFFeS51byDYfOf1ECu31n kOgMnO+heHt8hg6RPDP03FRtdTXZ46bDpCnJTqOrutzLU6A3CidBK0TfBlCcOZUVxXhFjUPo74fD /CbcJnHoR5NX4BbWcKO8DG6U3oktjDitpSq81Z+vQsqqCQ5BKrThHc8cg15ldJcRzIN7yxPQJraG GwVN85xp0qsZ4I1tFF3HBBKFxkCMwtCKq/bfIV9wjIJtSIm2lIPoBGzEWoccbbi902mGFyhoVPjE fRmIadGKcUVl9DNSF7BMlvhGd0rjy4Lui5mycnWmyjxlskhhmlR+MNpkOn9zwgMeSIE1HK0kC2kh ZahOpaJy4ZCL9OYU0bO6X6INIKGp3HUaXa5xj8SYOj21wRjYKnDkOeSzXmMVXXuU4qmVsYlTYhLL k0RsyGogcNYTlUAumUOE5rW5jdw2RMYOA2tFJpKlcMcKB5u3o6Q27pXABreWZlXXJkLoG2hx9iFa NnD9lDqDHUeAKAzjVo7BX5FCJ7eBXFDWcsEJ9EwVopMCxjsQk7qpYBK4GIu/NiJxxnvOIhNB/NaJ yaEMA3TZflfmsYNrO0yHYu2ga4vFxOhcPYlH0vOuKTqoBkS7+o09hoHagsf3bjiqW8Uz43XpANcT 3fawtwjjaoI08l1Hbi26DoLLa1DF2k2hWVlTh1GKBZ0qUmEj0W0ZNt2HsLfXiW5uRtH8YABfT1AJ +yz2qk6wDyAE/a7wFhTDeOIcz4HCQdU0SxSQnNTlvXVZG9bdjqfPVk2nTzeA/EqlBW7aJKpodFJh mg1wYfKj7l9dHD1lCgy0xVxAd2nInu1NaOXXi/nA0lKwjtUaqlM2qXozYAlZl5g2RiJ01Sn1i0RR FIv/ovejBZ0BUI+39gQwfbFRVNT2RiaqcDURbjDhWgebuHZgfn/rNqAKh1ABRf7sO3YD/czyjpBI R+gYRxRO/VlcM46a1CDhGKzKndpCiLUlMMHsdQYTjSI/CDsMpsVbXcO72SpwCyRjJ71TW7ZzuthW 5OKRFzu2U2xHYCAgwMJGJrZCPqz6vR9gCZOs34vGI0OdwtnUn8QsjIDQRT5w0a3o9/5gRb93sjpo dDhHQk/sLq4s5FsBnftR7iA1T0CapUHSLiOL+INARKZ8B2jitqqMG1RPmaiN/P117dOJPyduObSR MvzRIKjiD6gTSxiGnM3Ey5wGMyM2jOevpvSEp6IY4ieKaoURCj4MoYpYFE1NPPcE8RUQWAPC0J+8 BoHYdZWGKTCCYQCsBbQQeQfXDr3hw63QamtAYKJfmJozdQRF8wh4N4FJ4AkcO1fAC19wh04GWi6O pgalv+LjaO6PX8X52I3fB5mmuXBJPMl58p/Oy2g5VSQIw68yl1qlgyAi5mrZaBJrk5gynt2Lk6qt UUehRDg7QDzu0293zwxSJiY5e5NCAsN09/xf/71jNznEVpIvgHt/SRwVMigwRAvP3Uq1F9mRs2lJ +ARcKClWaI+S7GJQ7khPLP8/KHdEB/JyUO7IGqMSS5IzcOaqwN5dKgHBbFS+ZzdKZLtNhaHA+AOi LrcQF6cGscSo8VXNQZS3Eq8yNSXLL4vn882H/XpE+5g82Mukoh6G6ClA4HSRaBTBLjbpkW0SVRCA TvG8tJoRvbTpOMJmMwpE7KABZgwsI9T2PURhjQLAbfhBjS7ENgRJmrkQjJ1tnTrp8O3f24OWlpK5 wGznhTTZTcEcY5FWQtF5osOkU/3mTVsBlVfb+FOEme0NhtxqgXKtCXZ3OELKwJrlSxFnkK5oAL/r dILuC5nCbUS//h7DV6IQnqqz3P1DqLRQVSxf2hp9Pdb1oNKIzHGzwg14fm+BwNgeRMbWshRJiv3w bZbYawLFv9JRwrIud0M/pGVbcVn+uHKcw+HAl/QS/eVr6chsi7OKA/Oo/Pm35HG5Ty8z2UK+H/Bh cBHKJmPXp5P5p8wq+WnTDXpfgpFbjxkowsb5p7am57BYpjC7lQQkMh0PQu22Smy699Wantt2L/dd A5+v9l297yZvwLhZu3173GcCu32H9GjpDnu7M+RQ66JUnHkWoKYPWDN2Dke7x7CHjfYX99jACu/3 rbl8V3EAkEZuiSsG3yQqGEiT9PjxFjUffnGLTTr0+nZSsi2DoNzstECNlBh8ZEUpqJHS/pZmVFgl pblaVsXnLsZsomZA08Q0+AOYiqptBV/8kYry3w7KHhuH+JmYY+7X4uGjYdhnuI7na5U3VWIc0KKW xQjLijuiC7fnodRGHmbSaILkdhLd91b0bXE3mz+Do3OHrdtv0/Hkfvo40T9vZnN9EV1fT54Wk7H+ 9RQ9TebPHf1jPrmdPi/m0WI6e9R3xpNFNL03K0aP43qth0692uzhYTZ+5x1r0xs6D1x/gETyeoZI lI1z0JFHZeIVKiqWaDKyM798kEuwFVuJ84zOstezH/HrQtJV4PFBwIJBnTadNIsTbR4NFsGAVQWX kmfrouJZvhY7LteVI6UDzU8KtYqdkxQKBzi7h7PnnAPtrHKhzyFa32/Q7KxyDarZOaJNs26/lQOs 9jBzGp7h995mps4HkAPt+woNjLQdwAbbDbHL+l/IP/YZsGoMG1oMCEqyf6pEJTASyD18+oqZiAMb sI6WeS71g75Xhwpr+rQ8OMY24Lc4yvVvEBv0nRR8RnHKcofh/7gSMT0oMnwsyTZ5KVcxp3s5ADTG Z7moTgr+Dzg04x8NCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMCAwIG9iag0KPDwNCi9Qcm9jU2V0IFsv UERGIC9UZXh0IF0NCi9Gb250IDw8DQovRjQgNyAwIFINCi9GNiA4IDAgUg0KL0YxNSAyMSAwIFIN Ci9GMTggMjIgMCBSDQovRjIwIDIzIDAgUg0KL1QxOCAyNCAwIFINCj4+DQovRXh0R1N0YXRlIDw8 DQovR1MxIDE1IDAgUg0KPj4NCj4+DQplbmRvYmoNCjI1IDAgb2JqDQo8PA0KL1R5cGUgL0hhbGZ0 b25lDQovSGFsZnRvbmVUeXBlIDENCi9IYWxmdG9uZU5hbWUgKERlZmF1bHQpDQovRnJlcXVlbmN5 IDYwDQovQW5nbGUgNDUNCi9TcG90RnVuY3Rpb24gL1JvdW5kDQo+Pg0KZW5kb2JqDQoxNSAwIG9i ag0KPDwNCi9UeXBlIC9FeHRHU3RhdGUNCi9TQSBmYWxzZQ0KL09QIGZhbHNlDQovSFQgL0RlZmF1 bHQNCj4+DQplbmRvYmoNCjI2IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnREZXNjcmlwdG9yDQovQXNj ZW50IDANCi9DYXBIZWlnaHQgMA0KL0Rlc2NlbnQgMA0KL0ZsYWdzIDQNCi9Gb250QkJveCBbLTMg LTIwMSA4ODkgNzY1XQ0KL0ZvbnROYW1lIC9DQkpBTUsrTVNUVDMxYzg0Yg0KL0l0YWxpY0FuZ2xl IDANCi9TdGVtViAwDQovQ2hhclNldCAoL0c3NS9HM0EvRzQ0L0c2Mi9HMjcvRzQ1L0c0Ri9HNjMv RzZEL0c0Ni9HNTAvRzZFL0c2NS9HMjAvRzc5L0c2Ri9HNTIvRzY2L0c3MC9HNDkvRzUzL0c1NC9H NjgvRzcyL0cyRC9HNDEvRzY5L0c3My9HNEMvRzc0L0czOS9HNDMvRzREL0c2MSkNCi9Gb250Rmls ZTMgMjcgMCBSDQo+Pg0KZW5kb2JqDQoyNyAwIG9iag0KPDwNCi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl DQovTGVuZ3RoIDM3NzkNCi9TdWJ0eXBlIC9UeXBlMUMNCj4+DQpzdHJlYW0NCkiJTFNpUFNZFs4D 8nJdiAuEns5Lv4fdWlLtGiABxtZuBHyyOLSoLCJgwABhJyFACGsA0REQZAkJBBKWhLA02GHRuNCK WmqXKM50t1OOC1LdNV01ljVtT9/ADc7Eqf4xP26dU/d+59x7v/N9GMPFiYFh2Mag/WGBh8K3HTpy 9KgPP8XfN/n97g7b3rUetfbdPBaPh5NMUs8I/c+5c7+HtSxYvB5q18EXGzp460wbGZ9gmAtrtet6 N48PedTHW7y27eT7+v1x7xdBB0IjIqOOxcYnik6l5dN+AtonkPb1pYXetLcf7SugfQ/QQh9aGEz7 CmnBbloYQgsFtPdu2i+AFh6gBd60UEj77aZ9A2iBDy1wFPrTfo5aB55PCwNoPx/aN4j286V9Amhf Rx5MC/n/9w8Gtt6TsZWxgxGABTKCnEMZEVgkFuUkchJj6Vi2s9RZ4YC0YuewHmwAO4PpMSN2FqvH mjAt1oeZsAasGVNjnVgXNoj9GWvEWrAOTIcZsPPYBawd02DdWC/Wj9VhbYxPHEwynBhMxocMLywE S8QanY47PXdCzn9wFjgfdC5y8XeZZ0biPngYi8VqAvvBm1XBq7pWTaxOXD25Rrzmzdr9rnzXVtd/ sjeyV/zZKydskTzcnRNpX2AiER5pW2Cy7eRSm03LWfGCQ0teOLuf53Jx6REHuZUikPMxmbMpgf+n L8L3ffbl9mSQvB2BIvQRcSK+sTmWimuWNCmbALw8yNJVGatGq0DlqPX0XeKKtbnjEnWp42v9iGl0 0DRumO6d1t5seRAtOS5NUABFYlT1QSLmeLMmgTqhOakXD8ZYUq5n3wfZ90ufveE+6XhsfEAOPBi/ dfWq9cqd8XkTMM4/0SwQC0/KZXPUnOx2qjVuNmpqv8kbDPK1iIE2cu3MWc7TmrnyGbJspnhCZlbo i7XyNtBaKGuSEvLC06pCqlBVVFosVxSV5VakggpxbXISN745RZ1FqrO6pAaFXtFXbqwB1cahMyOE ydTYYqbMLb0tuhZwob6tXkPWa871mLhsu9k2tZTDQb/aPoK/4u+gy+8ZG66r9bCd5THnmbZPcUey vItpd8N3wltMeyq+E91i2vJtjzlom60CbbdXMNmLSyOONlIUMgcJ9AGFPCARCqPgWS6sfAC/hB9A TxJ6OkLIYygl7tyoq7VS1ppLqqmK0arxMkuJRTFc2lcBEExlKToLuvMMeYYsQ7pBohfrRFqgTU5q SSSOHVeVJFKJJaKcZFGqODtGFg4Kwio+9+HuVO/tjyD7IoZjLeKvxVN5ViUouWKtthJXrS2dl6jp zovd5p6RHrO+39CvN3R3d4ER9AueV55VmqZMU6aWiSsTypIqUxxsJR85E0ywYR+PeWdJyUFUFlof iZxIx9rnt+vwvji/jN1loIz/ac0Wwn7KQY7tJP72dU35T9RPZS8zn8a+jnginN0EZjcNog1oM9fu 1sh5XfI8Y56UzMfeCLHEmaK1RxpBw9GDDfuImnf+F/AXj+sbb1G3G2/oZkbuXrTeGHoIhh92Pn/N ZRfDHR6OC5Yr0PiKK9LYnqJx+1P72iVXNM5ie/NcSnguk5wVZzRqm3eczK+42/H3cDnORhPL6z1W LLADSpYTkAR2LFlQB5K8S4ASnO3JcynyeCd9/3TAQ+G2dzjbdomH13jYWcu5OOpd2cBEF3BkWNrA fJeL3r7HBbLgsxUZ/PuSjGkLdAjjGo/5cqmUg2rD0WHEQSSJSOSOgg6gAgLJUPAj6IncKeQGPcMd c1dxYfW38DB0gxQJKegOg+ehjIAFMCgEkdCdgo4G36IoVMO1c+o5i6ofFPfI4nuymWxLpiVtMFkH dCnJrUlEokilTKVSlWk56aLsU9LY4nBQHK7a58Pd1fq5LpLURfbFDqUMi8ZyJhx2tExWTxHTU63d E9RE95jZbBma6r/WdRt03W79/mcue47HZC+f54RUhhYeIuURmTHJIml+rixbni2XFKeVpipTKkTV QHUyvi6aQLF2pR28Z+Gv+MvvqpX3qHvKW7JrklnxVNzQIWA+pA0UcO0bVZzJqrEiM1lklulz1ela SWtmA2jITGo4SkTbowbwsZFz9UPUkLHxfB/V06hvNrQZ2rra1er+Pt1AixG0DjSNXeayYQqP+W8P ezxu59ummIhrn/rfTG0/48/+Ult1l7pbNSufyfxGMpk0HAOGYrQH93ARLt0ZG0zGBh84IhCBrbbN nPGa4VIjWWaU6TO0BW35zbkOveWkNYgItMG+5Td8ZrqxeYwaax7S9Ov7dLre9gGgHmgeneSydTaY x0HMre0GASUw7DEGjgD42yjru/Bn8T9KgOTHVyUvCL2poekr6qvzphZ920C7oVPXA3Q9rcZR7nip OaePzOlN70ppj+041hGlPqyO1sTpEMsScDPuEYh7KF14y4XUHciEqxbIBbgabp2GwcTiokrxilpU /E36KBugf2SwjloPWvaMgOHPArr8iYycM3X5VP7pPFVOeUFlkbKkEJQUVhfkc8UdWUY5aZTPFD1R XKu4Unm56nLl1dJvFL+If4i7FgGuR/T7b+Yir8NoDQJ8ko8A4ieiOIIttYV5OHxjD4PjPJcFh2/C HR5gsaOXVPAyB5azImtP1KbWpdWlqdIrsiplyhI5KJFX56ZxozVppiKyyDSpukkMDV3QDFPDmsHu gQGA9rvIiuSKYmWxUqrMVGYpsyuzq0F1drJDPF4BI3OhVNiDjBf/4j7vmhuZIUeuX5m4b75v/t6w qH6l/m/nZRvT1nXGcSXxy9k0WdUkR8m99N7ES1ztS5tsWVupajq1aZKG0q6FBAwLJLy/GNvXGBts g7GxIZAOsGP7+voFsE0wEGxwTGIaXsJLaCBK0ryItuladQtTP3TSCkvZsTlm2yXrJq3Svuz7I/3/ 53+e5/ec84191Qas/CXVldNBIph/jD6An81r1meRWfqTddkqUA2DvLBj3vkZA5jPHtke4fAk3FOZ vkKupMd/jnZhm13oL3yBO7mZuCuEHO3vKyaIiYrs4Ju4VNpilJJSo1Qv04DUIj9gDFiC50BrINge wL+6FZq/Qo7N934FORhM2oToWD7af4ClHNp+EHGy0G48M9fqKiQL6YKe0/36zF3oMbth4VrqGm86 fj0yw66vmSXmHg53rubsf0De3z+CROg4JkC5ycPVwhdedAYPk68Fjo9kTmZOFCxKl4F0Wff4W+xv 3q/DnxLhTz5cWpic+/BO5BM/8H/6iP4SX1psbmDnqmFJtSQFaKaA3+DSutUejaeWqWGUjMxZ5QAO aVlXMf6Lo1UZuWRuRs1LIgxxL750PYvIvH5P8RiPR7scw2TYEaKDTIDpYbxuj9vN0DSIoxmexqQy Uk2UQWFSmCuMVWZZC2ipLm7LwwVvJ09VC1EZenFqDXFJxFl9H+6Dv8Fg+gwUfwe3E3Dbd1A8B9/D 4WtQ+NsX/kg+fv4q2o1+jaGfbnbxO7KdBd3lvvI++ZBmQB3Rx0zAFLvaOoHHYp32y+Rl+wg97A7R /UzQHWR6XG4ajKIrPJmBMqqMNcYqU6GxxFjcXGQBlsK8NlaDn1QJ25a181WXQbRK0vMWfuyUuqiE LClUZ7W+CQQpU/JPadyfCBW8xk51l9wKrHJFpxI/ktdIKUmKMuQewUxwAJ1D3r/vQGsbO9AeeA7u GeLDZ0f++uAe8fFDuC0C9+PT19pa4+TV1mjrJQsQXErj+HaiJ4lZ3njb+LlxonXcPGz0G/q0vlon cKqqrSW4TGYxykhZk1RbqQKbo2jtX80wy78xMRedZZth7iZzG4e8ldI3bpKLbwyK0LOYYFOcUO9k XUC4xnPAQ8IUF15McHmC5C/TuNM7Ewv8ufZrbVGiLWoZMgaNQZ1Xw8qpt+QoymJgZ94g10nVW3JP 2OLZ74vNl7aK9V71VrHMWorLFOZGOalooPRU/VNvW4LoGdbabHSKtTZ1g7mF37uprbpOTlfGcvvT 7y7dmrgZBuGPFr2LbBQmHbsitBHlQOVQWeCMRwI8Elv6K9imnP9/JfMf9f8djD6NE08sCFFGDhI/ t5fYK0aiU+htHKUj0cy6mBSv50AxzMDgO9NQvLpOrK9C0QxMx2E6FJ3cu0qu7p1GYpSBoY024Z2W +aY40RTXj2j6NSFVN8X6oqqtlbhU3mKkSKVRVa9WaChdmSEfGE5b3j+GHbVmOs8SzrPuCp/SRwXq QgZgCA1Zwuz70EoPkAN0wOcN9oY8EUcMOGNd8w8xgSONczexLETHT6N9B58y4sAWI3b9FyNAqpxt C+4/2NP/iP8DRnybve8B+eBnI2gPOoqhpFkIt2k/r5wiJiuy+478gFRLfF9zr8XPksrf3z6I/+FW //zYv0klSO3eAMlhoYxt/7pOil2vSvnvqvHSEouxiCxsKm4sbQCb5u/v4Fd8D+PvDvlD/ou+ANPn HnQNs+GEh6yDNN3O4Ey7q93ZDgRIlZBJhS+/ave9Tr7ue6c3Lwjg5ADf29jd0Kvv1Q3qorpLutHG sSbQNBZvmcAnr9o8UXLU3R0MYxdN3VqG0LoqXBKaslbYii4UXiizSx2H+t+K5c+Cgtna+yvYFH0t ECcC8eHYeCQenuu/0wN6bi87vsQ/f9isu03e0c3Xj9cCNCrnG+x1NOWhPEqXkpa5Kp1ldnChrLSr BJecMWnLyfJ6rUqOURc0vgbCq4823GgYbI6Yo+bL5qgpYviCWiwek4Arkt7jL2OnGiU1eYQyr7wo vyqvLFNxog5oThw2HcQFqcOJhVohEu0b+OgEeWKh6s8QwxJ+hLGcwOAyG9syXGH5sZIS8YvOV3wg I6qtlF1FOGo89UH21RuIWMZxX1/n059Er422gUF0nldiLGo+yzLsTHZbBr41NXZ27uEzvHdzMosl FKBy3m08iqMdhyL3M8iM+9J1KMKScviE5cd7H+R1lBEdpTYprXTUeLV+thv9Q5YY3jdgpVma00Oe UC9IjsI1vuC5NA6zAYWppbSNbdzUj3nw1UR66vmNL7iJ7Txo2MyCimQWV4A6YEcacJ3npXE2hP8E bHOCog0KZW5kc3RyZWFtDQplbmRvYmoNCjI4IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnREZXNjcmlw dG9yDQovQXNjZW50IDczMg0KL0NhcEhlaWdodCA2ODENCi9EZXNjZW50IC0yMTMNCi9GbGFncyAy NjIxNzgNCi9Gb250QkJveCBbLTE5NCAtMjUwIDEzNDYgOTM0XQ0KL0ZvbnROYW1lIC9Cb29rbWFu LURlbWkNCi9JdGFsaWNBbmdsZSAwDQovU3RlbVYgMTY3DQovWEhlaWdodCA1MDINCj4+DQplbmRv YmoNCjI5IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnREZXNjcmlwdG9yDQovQXNjZW50IDcyNg0KL0Nh cEhlaWdodCA2ODENCi9EZXNjZW50IC0yNzENCi9GbGFncyAyNjIxNzgNCi9Gb250QkJveCBbLTE1 MiAtMjY2IDEwMDAgOTI0XQ0KL0ZvbnROYW1lIC9QYWxhdGluby1Cb2xkDQovSXRhbGljQW5nbGUg MA0KL1N0ZW1WIDEyMg0KL1hIZWlnaHQgNDcxDQo+Pg0KZW5kb2JqDQozMCAwIG9iag0KPDwNCi9U eXBlIC9Gb250RGVzY3JpcHRvcg0KL0FzY2VudCA3MTgNCi9DYXBIZWlnaHQgNzE4DQovRGVzY2Vu dCAtMjA3DQovRmxhZ3MgMzINCi9Gb250QkJveCBbLTEzNiAtMjI1IDgyMCA5MzFdDQovRm9udE5h bWUgL0hlbHZldGljYS1OYXJyb3cNCi9JdGFsaWNBbmdsZSAwDQovU3RlbVYgODgNCi9YSGVpZ2h0 IDUyMw0KPj4NCmVuZG9iag0KMzEgMCBvYmoNCjw8DQovVHlwZSAvRm9udERlc2NyaXB0b3INCi9B c2NlbnQgNzMyDQovQ2FwSGVpZ2h0IDY4MQ0KL0Rlc2NlbnQgLTIyOA0KL0ZsYWdzIDM0DQovRm9u dEJCb3ggWy0xODggLTI1MSAxMjY2IDkwOF0NCi9Gb250TmFtZSAvQm9va21hbi1MaWdodA0KL0l0 YWxpY0FuZ2xlIDANCi9TdGVtViA5Ng0KL1hIZWlnaHQgNDg0DQo+Pg0KZW5kb2JqDQozMiAwIG9i ag0KPDwNCi9Qcm9jU2V0IFsvUERGIC9JbWFnZUIgXQ0KPj4NCmVuZG9iag0KMTIgMCBvYmoNCjw8 DQovTmFtZSAvVDINCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTMNCi9SZXNvdXJjZXMgMzIg MCBSDQovRm9udEJCb3ggWzAgLTE1IDYxIDU3XQ0KL0ZvbnRNYXRyaXggWzAuMDEzMzMgMCAwIDAu MDEzMzMgMCAwXQ0KL0ZpcnN0Q2hhciA0MA0KL0xhc3RDaGFyIDg1DQovRW5jb2RpbmcgMzMgMCBS DQovQ2hhclByb2NzIDM0IDAgUg0KL1dpZHRocyBbMzQgMzQgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIA0KMCAwIDI3IDAgMCAwIDAgMCAwIDUxIDAgNTAgNTcgNDYgMCAwIA0KMCAzNiAwIDAg NDMgNjcgNTggNTggMCAwIDU0IDQ4IDQ2IDU1IF0NCj4+DQplbmRvYmoNCjMzIDAgb2JqDQo8PA0K L1R5cGUgL0VuY29kaW5nDQovRGlmZmVyZW5jZXMgWzQwL0cyOCAvRzI5IDU4L0czQSA2NS9HNDEg NjcvRzQzIC9HNDQgL0c0NSA3My9HNDkgNzYvRzRDIC9HNEQgL0c0RSAvRzRGIDgyL0c1MiAvRzUz IC9HNTQgL0c1NSBdDQo+Pg0KZW5kb2JqDQozNCAwIG9iag0KPDwNCi9HMjggMzUgMCBSDQovRzI5 IDM2IDAgUg0KL0czQSAzNyAwIFINCi9HNDEgMzggMCBSDQovRzQzIDM5IDAgUg0KL0c0NCA0MCAw IFINCi9HNDUgNDEgMCBSDQovRzQ5IDQyIDAgUg0KL0c0QyA0MyAwIFINCi9HNEQgNDQgMCBSDQov RzRFIDQ1IDAgUg0KL0c0RiA0NiAwIFINCi9HNTIgNDcgMCBSDQovRzUzIDQ4IDAgUg0KL0c1NCA0 OSAwIFINCi9HNTUgNTAgMCBSDQo+Pg0KZW5kb2JqDQozNSAwIG9iag0KPDwNCi9MZW5ndGggMTk4 DQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSImckD0KwkAQhVdSBBaGHCFzAck/ WwpRwRSCVh5ALS0UrZOj5Sg5QsoUknFmzSJiZ/ExsPPezpvJcowxx3lSYJZgYfCUgL6CTg2/x2jS qXm8gC4r0NEBU8Nlwy0u5W6JbIiqLd5vjzPoaoU0qJB6y4I6VVOriJoZ4xEpn0ZLQE+WCAPLhJ6l QsdyC1tah/dGvmj8b5QQ/In/+1/jfea5+ZLF5XI5XW63h+w0qimQDSpma6rtLXq7bAh6zYfcg34J MACjz7m5DQplbmRzdHJlYW0NCmVuZG9iag0KMzYgMCBvYmoNCjw8DQovTGVuZ3RoIDE5Nw0KL0Zp bHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJnNA7CsJAEAbgCRbCwuIRMheQvAxbClHB FIJWHkAtLRStk6PlKDlCyhTBcWY3iWhp8bGww87O/MkCQ0xwHqWYhJgaPEda3bSKDd+HaOK+eLpq leVaBUeMDR9bLvGR7VfID4J8h4/786JVvkaYEIFHVLIKiGooqIEltawDn83oxQimTjlxKs+pwWms wmpH0uSXzw3/4wb67tda7r9m9JlrmHOYu99Dduos37aQnWV3yUCykEwkG602HORBq7cAAwBIZbbm DQplbmRzdHJlYW0NCmVuZG9iag0KMzcgMCBvYmoNCjw8DQovTGVuZ3RoIDkxDQovRmlsdGVyIC9G bGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIkyMlcwUABhIwMFE0OFFENerkJeLkNjoAhYACSVnMvL 5eTJy6UfrmBoDKQ8gBJAyinAWQFEe/oqlBSVpvJyebooMLDjhv9xAny6eLlcgVYH8nIBBBgAo7Yq bA0KZW5kc3RyZWFtDQplbmRvYmoNCjM4IDAgb2JqDQo8PA0KL0xlbmd0aCAyMDANCi9GaWx0ZXIg L0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiWTRPQ6CQBAF4EcoSDbZcAT2BkqxNQQ1kcJEKw+g lhYareFoHIUjUFIQcR7+8Jfd5NudneJN1oZm2S0bGmvNOdTqppX9VKVATletklSrxVG6hK08CMl+ ZXhNd+Zxf160StembQtkbfsnRzQHCGa8AH9GA3gzasAdEpMKsTOkJCVKDHAqUgjZgJrkbs1oY+A1 jDbiBV92Dxi0Id6EmrgTKuJMKCVBgR4m5omVHw6HyvKO6IfL8SN0BF+02shPHbR6CzAAwEHaNw0K ZW5kc3RyZWFtDQplbmRvYmoNCjM5IDAgb2JqDQo8PA0KL0xlbmd0aCAyMjkNCi9GaWx0ZXIgL0Zs YXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiaSQPQrCQBCFJ6QQFhaPkLmA+EMS7QR/wBSCVh5ALS0U rQ14sYAXEbzAgo1FyPh2N6LY2nwD+2Zn3rykwx3ucavL8YCTlDddrfZaxSlbIel7bb3TapRp1V5x nKLMoKCMFmNGfzub8/Fw2mqVTVjkSUMRySkQqYjojAeiptzAUArH3JEsK8fSEY3nPDSQDNiQMrzh YwVGIpfCzr0WGCj3grDikVtKzeBD8gz/ZvA7ueZn7+Ptx3rzPr1n799ghKnvKr8u9Vf7BOpMbD4N MWAkpcsNG6wNm6dWU8S/1OolwAAshMWzDQplbmRzdHJlYW0NCmVuZG9iag0KNDAgMCBvYmoNCjw8 DQovTGVuZ3RoIDE5Nw0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJMjVXMFAw A2JTUxBKMeTlKuTlMrEEioDFQFLJubxcTp68XPrhCiaWQMoDKAGknAKcFYDK9T19FUqKSlN5uTxd FBgYGOz///8PpBghFIgLovghFDOEYoRQDFCqHkLZQyj5/0BlIB1A6gEDO4j6AKH+gCSY//+DUP+B xiBRDVCKAUwdwEY9YKinHoXVBqjtDYyYDoS6GuqHHxAfPYB4E+xbqN+RQqIeOZSgYcaOEp72yGEN CnleLldgTAXycgEEGAAZHapCDQplbmRzdHJlYW0NCmVuZG9iag0KNDEgMCBvYmoNCjw8DQovTGVu Z3RoIDEwOA0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJMjFTMFAAYRMjBVNT hRRDXq5CXi5jkIgBSADESM7l5XLy5OXSD1cwNgNSHkAJIOUU4KwAVK7v6atQUlSaysvl6aLAAAT8 pBHM////J40AAnvSCNLtwGc5aR7k5XIFhl0gLxdAgAEACyRegA0KZW5kc3RyZWFtDQplbmRvYmoN CjQyIDAgb2JqDQo8PA0KL0xlbmd0aCA5OA0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJl YW0NCkiJMjZTMFAwBmFjBVNThRRDXq5CXi5jAwUQBAqApJJzebmcPHm59MMVjA2AlAdQAkg5BTgr AJXre/oqlBSVpvJyebooMDAwMBOD/wPRYMHEupmXyxUYCIG8XAABBgAnR1YqDQplbmRzdHJlYW0N CmVuZG9iag0KNDMgMCBvYmoNCjw8DQovTGVuZ3RoIDk3DQovRmlsdGVyIC9GbGF0ZURlY29kZQ0K Pj4NCnN0cmVhbQ0KSIkyMVYwUDADYhMjBVNThRRDXq5CXi5jkIgBSADESM7l5XLy5OXSD1cwNgNS HkAJIOUU4KwAVK7v6atQUlSaysvl6aLAwPz///9hTQABP0kEL5crMOwCebkAAgwAzZaXcQ0KZW5k c3RyZWFtDQplbmRvYmoNCjQ0IDAgb2JqDQo8PA0KL0xlbmd0aCAxODMNCi9GaWx0ZXIgL0ZsYXRl RGVjb2RlDQo+Pg0Kc3RyZWFtDQpIibTRQQqCUBAA0BEj4cPHbuDcQFto7QQryEVQqw5QLVsUBS0C PZpH8QguXYi/Gc34H9cxM7xhZnYTLTDAiGuOYYjnuRQ3KagLKAhena5SJKkU/pEmxLYn2a+Qzv10 h4/78yJFukYApVqwmIbJBmomNvBUZVAy7kDBOAa2yg2Asb60HaAzgTfkP6bwsjqWPQHjwMzWyClH FOBqlOCNqSDWqCHTaECNUepPSLGhTx2k+AgwAKOogYMNCmVuZHN0cmVhbQ0KZW5kb2JqDQo0NSAw IG9iag0KPDwNCi9MZW5ndGggMTc2DQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0K SIlM0DEOglAMBuBHMJI0eeEI9Aag4RE3EtREBhOdPIA4Omh0hqNxFI7AyEDAPoHkH/q1aTs0NTuO OJEwWzaGi42ml6bYdiLbsMX9qSnLNYU3jhNJJxlIyi57lvUwP/Pn/X1oyg+sVDlWrlIpGIA+6IEu 6IAKLcFUXM0G4nrWF71Zz1pNutZ60rE2k8ra/u3kgMUeHMARrcAabMAW7MAeHMBxUdNRXn7V9BNg ADIYXlYNCmVuZHN0cmVhbQ0KZW5kb2JqDQo0NiAwIG9iag0KPDwNCi9MZW5ndGggMjI5DQovRmls dGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIm0kbEKwjAQhq84CIHQR/BeQNpKo26FqmAH QScfQB0dFJ3bR+uj9BE6dhDPv/UcKq6GJB8kl/vv/rg5hzzhccRu2s5jZM3FGhfjOGQ3e98dztak mTXBnl0MrHEDpNsFIz7INny73k/WZEsWaSgXjIKG2B9EBNRAIlIBI5ES8EWw00CeLbwuEKGKhjyc 5zVyFJTUiC4pqfAWq0KmmkYlZBryS2pFPig6DAtPkPcL0ILm4B/4qae19AvUqrUH7Uj7024bIriQ 9w1Rl9Szj4Pqp7qrXqvz73+wZoV/21nzEmAA/InDhQ0KZW5kc3RyZWFtDQplbmRvYmoNCjQ3IDAg b2JqDQo8PA0KL0xlbmd0aCAyMTINCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpI iYzRwQqCQBAG4JU9CAuLj+C8gQatV8EK8hDUqQeojh2KOq+P5qP4CB47SNvMjpZ7C5EPdtZ/ZtAs IYcCX1OAMXBeaHXTyuRADx5Q6XTVqqq1yo5gcmSLBaTarwCvZ/UOHvfnRat6DUKI2DmHCMukTMJI JgoQI/aLdCOtKIkuoP+bjlO6KczTUD/5ntpGwWQjcTB8ybgA+6vJzt+U/QRtK18+RQ4+E/tFM5zv TrPM12zxez9uyjskBMV4JDEwFMOzjliiEaVWG/xTB60+AgwAfjOmHQ0KZW5kc3RyZWFtDQplbmRv YmoNCjQ4IDAgb2JqDQo8PA0KL0xlbmd0aCAyNDYNCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0K c3RyZWFtDQpIiUTQPW7DMAwFYBodAggQcgTyAkESVPnZBKQtUA8F2qkHaDtmSNDO1tFyFB8ho4bA LPnsossnWJTIJ6e9rOReFmtJO9ls5XMdwymGlGx7JZvdWPs4xnBoY1i+S0q2PFvFlsPrg9j5Zfsi 3+efrxjaR1Etd6paiVi1J2psg4jyQO4NVniFPbxMcqVcqFPTLvbZr9dM1nGAOqqTDaRRhr5V8FH+ h6v3n3scu+g2iumKPN2YbTrqZUbBelz8mg7QPtwrrPBG8wwZzqBHJrZHuGz92MYVyoQpsINKSEJI 5c6Qk5Gt+3tM9RwxPNnvf4vhV4ABADUBmt0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo0OSAwIG9iag0K PDwNCi9MZW5ndGggOTMNCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiTIxUzAA QxMzBVNThRRDXq5CXi4TiChQAEQl5/JyOXnycumHA1UBKQ+gBJByCnBWACrX9/RVKCkqTeXl8nRR YAABZvLI//9BeJSEkLxcrsAgD+TlAggwAFaHw8kNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1MCAwIG9i ag0KPDwNCi9MZW5ndGggMTYwDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSInk kDEKwkAQRUdSLAwMHiFzAYmBrK0QFdxC0MoDqKWFonVytD2KR0iZQjL+NXgKh+F9+H9+M97rXL3O SvVQr+dS+CZcJRvGYsxOV+E6CBdHrTxkiwRS71eK+yLs9HF/XoTDWimzgdwfcWJvcm3itCXrf4zU dJTH774IsxzZJTZ9IiqE+gBmZqAzi0S5GY4agwVDeIPHH4Q/AgwAoHiE6Q0KZW5kc3RyZWFtDQpl bmRvYmoNCjUxIDAgb2JqDQo8PA0KL1Byb2NTZXQgWy9QREYgL0ltYWdlQiBdDQo+Pg0KZW5kb2Jq DQoxMyAwIG9iag0KPDwNCi9OYW1lIC9UNA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMw0K L1Jlc291cmNlcyA1MSAwIFINCi9Gb250QkJveCBbMyA4IDMwIDM1XQ0KL0ZvbnRNYXRyaXggWzAu MDEzMzMgMCAwIDAuMDEzMzMgMCAwXQ0KL0ZpcnN0Q2hhciAxODMNCi9MYXN0Q2hhciAxODMNCi9F bmNvZGluZyA1MiAwIFINCi9DaGFyUHJvY3MgNTMgMCBSDQovV2lkdGhzIFszNCBdDQo+Pg0KZW5k b2JqDQo1MiAwIG9iag0KPDwNCi9UeXBlIC9FbmNvZGluZw0KL0RpZmZlcmVuY2VzIFsxODMvR0I3 IF0NCj4+DQplbmRvYmoNCjUzIDAgb2JqDQo8PA0KL0dCNyA1NCAwIFINCj4+DQplbmRvYmoNCjU0 IDAgb2JqDQo8PA0KL0xlbmd0aCAxMzUNCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFt DQpIiTI2UTBQMFawUDAGUqYKKYa8XIW8XEbmQFEDBSAFkkrO5eVy8uTl0g8HigApDwjlFOCsAFSu 7+mrUFJUmsrL5emi8P9A/f9/DPz//zCw///AwPj/AQMDGB9gYKhvYGCwh2EGBgZ5XBhZHUgfzAyQ eSBzQeaD7OHlcgU6KpCXCyDAAFCXMaENCmVuZHN0cmVhbQ0KZW5kb2JqDQo1NSAwIG9iag0KPDwN Ci9Qcm9jU2V0IFsvUERGIC9JbWFnZUIgXQ0KPj4NCmVuZG9iag0KMTQgMCBvYmoNCjw8DQovTmFt ZSAvVDgNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTMNCi9SZXNvdXJjZXMgNTUgMCBSDQov Rm9udEJCb3ggWzEgLTEgNjIgNjNdDQovRm9udE1hdHJpeCBbMC4wMTIwNSAwIDAgMC4wMTIwNSAw IDBdDQovRmlyc3RDaGFyIDU4DQovTGFzdENoYXIgMTE3DQovRW5jb2RpbmcgNTYgMCBSDQovQ2hh clByb2NzIDU3IDAgUg0KL1dpZHRocyBbMzAgMCAwIDAgMCAwIDAgMCAwIDAgNjMgMCA0OCAwIDAg MCANCjAgMCA0OCAwIDAgMCAwIDAgNjAgMCAwIDYxIDAgMCAwIDAgDQowIDAgMCAwIDAgMCAwIDUw IDAgMCAwIDQ5IDAgMCA1MyAyNSANCjAgMCAyNSAwIDAgMCAwIDAgMzYgNDMgMzQgNTMgXQ0KPj4N CmVuZG9iag0KNTYgMCBvYmoNCjw8DQovVHlwZSAvRW5jb2RpbmcNCi9EaWZmZXJlbmNlcyBbNTgv RzNBIDY4L0c0NCA3MC9HNDYgNzYvRzRDIDgyL0c1MiA4NS9HNTUgOTcvRzYxIDEwMS9HNjUgMTA0 L0c2OCAvRzY5IA0KMTA4L0c2QyAxMTQvRzcyIC9HNzMgL0c3NCAvRzc1IF0NCj4+DQplbmRvYmoN CjU3IDAgb2JqDQo8PA0KL0czQSA1OCAwIFINCi9HNDQgNTkgMCBSDQovRzQ2IDYwIDAgUg0KL0c0 QyA2MSAwIFINCi9HNTIgNjIgMCBSDQovRzU1IDYzIDAgUg0KL0c2MSA2NCAwIFINCi9HNjUgNjUg MCBSDQovRzY4IDY2IDAgUg0KL0c2OSA2NyAwIFINCi9HNkMgNjggMCBSDQovRzcyIDY5IDAgUg0K L0c3MyA3MCAwIFINCi9HNzQgNzEgMCBSDQovRzc1IDcyIDAgUg0KPj4NCmVuZG9iag0KNTggMCBv YmoNCjw8DQovTGVuZ3RoIDk1DQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIky NlAwULAAYiMjBRMzhRRDXq5CXi5DEwWQOFAAJJWcy8vl5MnLpR+uYGgCpDyAEkDKKcBZAahc39NX oaSoNJWXy9NFgYEZP/yPBxDSy8vlCnREIC8XQIABAByQLBUNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1 OSAwIG9iag0KPDwNCi9MZW5ndGggMjAwDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVh bQ0KSIms0TEOgjAUBuBHGJo0aXoEegM0AisJaiKDiU4eQB0dNDrj0TiKR2BkIOIrf0lKdDSh+UhL S9//soWZmcyO4TnNlbwqmSY8gznmeFGyKJWMDyZNmA0vMMVuafjzuNya++1xVrJcGSLSfd8zlAMB AkAVyIEGAoQgANTzWw1a3sh0vBEnDTwpstTgRdqjGRGW9hcdhX/n54+aEf19T3d5VwoKe6NaV/QQ gZdLMAnLRRdNYq38yIXfDtscJdfczL2SHwEGAGCVnjINCmVuZHN0cmVhbQ0KZW5kb2JqDQo2MCAw IG9iag0KPDwNCi9MZW5ndGggMTAzDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0K SIkysVAwUDADYhMzBTMDhRRDXq5CXi4TAwUQNINIJefycjl58nLphyuYGAApD6AEkHIKcFYAKtf3 9FUoKSpN5eXydFFgIBMw/v//n1wCCJjJICixkioEL5crMFADebkAAgwArg2Bow0KZW5kc3RyZWFt DQplbmRvYmoNCjYxIDAgb2JqDQo8PA0KL0xlbmd0aCA5OA0KL0ZpbHRlciAvRmxhdGVEZWNvZGUN Cj4+DQpzdHJlYW0NCkiJMrFQMFAwA2ITcwUzA4UUQ16uQl4uE0OgiAFIACSVnMvL5eTJy6UfrmAC lNf3AEoAKacAZwUQ19NXoaSoNJWXy9NFgYHxPxCMkgRIEKinhOTlcgVGSCAvF0CAAQBWv9izDQpl bmRzdHJlYW0NCmVuZG9iag0KNjIgMCBvYmoNCjw8DQovTGVuZ3RoIDIxOQ0KL0ZpbHRlciAvRmxh dGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJlNGxDoIwEAbgNgxNmjR9BO4NqCawkqAmMpjo5AOoo4NG Z300H4VHYGQg1DuuGDpKaD5Syn93oXDgoKC1hMLBeWH0zeicdhxt0MPpanRVG50dIS+QLb5Aqv0K 8HhW7+Bxf16Mrtcg8PLeE5aRjAiUTMrYCMUkP6T/MC0uvPuI4V96Dgt0TENlpX9P1W3UYGj3NZ8h TKSiMW20mSCyH08i9J0cGD+GUb2SSXlMy71YnlbNGuym5gWPMkIxTElgDIExRDOhiFYkBMYQGGP0 Bn/mweivAAMAN5mgsA0KZW5kc3RyZWFtDQplbmRvYmoNCjYzIDAgb2JqDQo8PA0KL0xlbmd0aCAx NzUNCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiezRMQ7CMAwFUFcdKlmyOEJ8 AdRmSNZKBSQ6IMHEAYCRgQrm9mg9So/QsQPC2MDAyAGIFD8pP7GHRM8FB557DpFjwUdPeCEMdlxw 9O/scCasasJ8z0Ev5GtNlGq7YLPe8LW5nQjrJUMiMoL78xMgMoDrXpQdtNJ/UYruHpwAtD2kkzKA LfkwWk1kMlK5G5k8jJmI4UQ76TMbZiMtzBRtoIVwpX+6I3wKMAATn8YHDQplbmRzdHJlYW0NCmVu ZG9iag0KNjQgMCBvYmoNCjw8DQovTGVuZ3RoIDIxMQ0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+ DQpzdHJlYW0NCkiJfNC9CgIxDAfwHA5Cobi6NS8gp17F2w78AG8QdPIB1NFBUXCrj9ZHuUfQ7QZp TSIn4uDy65A0+ZNRH/s4xN4A7QjtGHcDrY5a2Qy5YPN3bXvQalJqlW7QZvQsqELPZDVF6k/LJZ5P l71W5QxjDZ0YAwC4eCeN2BZbYiLCW/dlcW8H1kUP5hGpwcTG+tfAo4MsqESeYIJYizLTVKJvpL83 KESeQ2HY1l85MFuR4ID/wkf/ZdXs7UqGHMwT4MrZEs7s6TBRqzkdcq3VS4ABAB9gcjcNCmVuZHN0 cmVhbQ0KZW5kb2JqDQo2NSAwIG9iag0KPDwNCi9MZW5ndGggMjE1DQovRmlsdGVyIC9GbGF0ZURl Y29kZQ0KPj4NCnN0cmVhbQ0KSImckD0KAjEQhWexWAiEHMG5gPhDRK0WVgW3ELTyAGppoWi9OVpu 4BX2CCm3WBxnsiqCnSF8M8ybJG9iZzjAEfaGaCeyD0OtzlrZMZcHaKettj9plRda9XdoxxxWrHDI N3Pk/n6xxuvldtSqWCCR7xBRA1ASBQDDBYCUyAEkRMBLxDfLWpgFMB6ySpJuBVRD10uD8cmLDzCu 82HaUo7+QfFH33TJD4Fx9zKDGKPGVDxJYCYEJsg9pv5inMVQSxdZRYpcstf4UOBUqyV/5FarpwAD AK0bejcNCmVuZHN0cmVhbQ0KZW5kb2JqDQo2NiAwIG9iag0KPDwNCi9MZW5ndGggMTQ0DQovRmls dGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIkyNVYwUDAFYhMLBTNjhRRDXq5CXi4TkKgB SAAklZzLy+XkyculH65gYgykPIASQMopwFkBqFzf01ehpKg0lZfL00WBgfk/ENCUZKgHkj8Y+IHk AwZ2IHkAJMjMwMD4n4GJgYHhPwMI1COR9thI+wYGeaDiB0CS+f8HDPLHUCN5uVyBURTIywUQYABz hKP7DQplbmRzdHJlYW0NCmVuZG9iag0KNjcgMCBvYmoNCjw8DQovTGVuZ3RoIDk1DQovRmlsdGVy IC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIkyMlUwUABhQ0sFM2OFFENerkJeLkMToIgBSAAk lZzLy+XkyculH65gaAKkPIASQMopwFkBqFzf01ehpKg0lZfL00WBgRkb/I8EsKugDuTlcgU6M5CX CyDAACMOHHENCmVuZHN0cmVhbQ0KZW5kb2JqDQo2OCAwIG9iag0KPDwNCi9MZW5ndGggODkNCi9G aWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiTIyVTBQAGFDSwUzY4UUQ16uQl4uQxOg iAFIACSVnMvL5eTJy6UfrmBoAqQ8gBJAyinAWQGoXN/TV6GkqDSVl8vTRYGBeSAhL5cr0JmBvFwA AQYAJVMQjw0KZW5kc3RyZWFtDQplbmRvYmoNCjY5IDAgb2JqDQo8PA0KL0xlbmd0aCAxMTkNCi9G aWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiTI2UzBQMAViYzMFEzOFFENerkJeLmND oIgBSAAklZzLy+XkyculH65gDJTX9wBKACmnAGcFENfTV6GkqDSVl8vTRYGB+T8jA/MfIP4AxAeA uIGRgYmBkYEBF+b/ycDw/z9Q34BiXi5XoAcDebkAAgwAKtpXQg0KZW5kc3RyZWFtDQplbmRvYmoN CjcwIDAgb2JqDQo8PA0KL0xlbmd0aCAyMTMNCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3Ry ZWFtDQpIiTzQPQ6CQBCG4dlQkGyy2SMwFzD+QKJUJKiJFCZaeQC1tNBoDUej8xp0tpYWhHE+iDbP kN3lXUIS84RjHk05mXEy59PU2auzcarLE04Ww97x4mxeODs+cJzq2OiOjny3ZD0/LrZ8vz3OzhYr lo68SEMkUhFFHRGFLXiD5k8NqoGsUaQNyYj0PMELDSEqgQdD0wMDqEQlQs/30c/vtkB6GhxsgT4q LZlMP9BEWjMhCACVHQXkPwpeAyHwIAIZKAGaAZraqDXp7Fp/zN7ZrwADAAABW1ENCmVuZHN0cmVh bQ0KZW5kb2JqDQo3MSAwIG9iag0KPDwNCi9MZW5ndGggMTM2DQovRmlsdGVyIC9GbGF0ZURlY29k ZQ0KPj4NCnN0cmVhbQ0KSIkyNlEwUDBU0DVUMDZRMLVUSDHk5Srk5TI2BgobKJhB5ZJzebmcPHm5 9MMVjI2BlAdQBkg5BTgrANXre/oqlBSVpvJyeboo/GCQ//+fEoIBCOpJIii2khyCH06wgwjGP/V/ QG5BEP/gxH8w0QAiDoCIDyDiP1AfL5crMFADebkAAgwANOyiIA0KZW5kc3RyZWFtDQplbmRvYmoN CjcyIDAgb2JqDQo8PA0KL0xlbmd0aCAxNTANCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3Ry ZWFtDQpIiTI1VjBQMFXQNVQwsVAwMVNIMeTlKuTlMgEJGyiYmEPkknN5uZw8ebn0wxVMjIGUB1AG SDkFOCsA1et7+iqUFJWm8nJ5uigwMP//wSA/xEhGDJLh/wMQac/AIN/AwICVPIBEPmBg4GCQ/8DA IMEg/4OBoYJB/g8DA9Cc/wzMIPKA/P///3m5XIFBGMjLBRBgAIEsaMcNCmVuZHN0cmVhbQ0KZW5k b2JqDQo3MyAwIG9iag0KPDwNCi9Qcm9jU2V0IFsvUERGIC9JbWFnZUIgXQ0KPj4NCmVuZG9iag0K MjQgMCBvYmoNCjw8DQovTmFtZSAvVDE4DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUzDQov UmVzb3VyY2VzIDczIDAgUg0KL0ZvbnRCQm94IFsyIC05IDUxIDU4XQ0KL0ZvbnRNYXRyaXggWzAu MDEyMDUgMCAwIDAuMDEyMDUgMCAwXQ0KL0ZpcnN0Q2hhciA0NA0KL0xhc3RDaGFyIDg1DQovRW5j b2RpbmcgNzQgMCBSDQovQ2hhclByb2NzIDc1IDAgUg0KL1dpZHRocyBbMTggMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgDQowIDAgMCAwIDAgNDMgMCA0MSA0MyAzNSAzNCA0MyA0MyAxOCAw IDAgDQozMiA1NyA0NCA0MyAzOCAwIDQxIDQwIDQwIDQzIF0NCj4+DQplbmRvYmoNCjc0IDAgb2Jq DQo8PA0KL1R5cGUgL0VuY29kaW5nDQovRGlmZmVyZW5jZXMgWzQ0L0cyQyA2NS9HNDEgNjcvRzQz IC9HNDQgL0c0NSAvRzQ2IC9HNDcgL0c0OCAvRzQ5IDc2L0c0QyAvRzREIC9HNEUgL0c0RiAvRzUw IDgyL0c1MiAvRzUzIC9HNTQgL0c1NSBdDQo+Pg0KZW5kb2JqDQo3NSAwIG9iag0KPDwNCi9HMkMg NzYgMCBSDQovRzQxIDc3IDAgUg0KL0c0MyA3OCAwIFINCi9HNDQgNzkgMCBSDQovRzQ1IDgwIDAg Ug0KL0c0NiA4MSAwIFINCi9HNDcgODIgMCBSDQovRzQ4IDgzIDAgUg0KL0c0OSA4NCAwIFINCi9H NEMgODUgMCBSDQovRzREIDg2IDAgUg0KL0c0RSA4NyAwIFINCi9HNEYgODggMCBSDQovRzUwIDg5 IDAgUg0KL0c1MiA5MCAwIFINCi9HNTMgOTEgMCBSDQovRzU0IDkyIDAgUg0KL0c1NSA5MyAwIFIN Cj4+DQplbmRvYmoNCjc2IDAgb2JqDQo8PA0KL0xlbmd0aCAxMTQNCi9GaWx0ZXIgL0ZsYXRlRGVj b2RlDQo+Pg0Kc3RyZWFtDQpIiTK0UDBQMFLQtVQwNFGwUEgx5OUq5OUyNAKKGigYmkOkknN5uZw8 ebn0wxUMjYCUB1AGSDkFOCsA1et7+iqUFJWm8nJ5uih84P8g/wAE7R/YH6gHw/8N/xuBsBkImf+z /+flcgUaFcjLBRBgAOFoJU8NCmVuZHN0cmVhbQ0KZW5kb2JqDQo3NyAwIG9iag0KPDwNCi9MZW5n dGggMTg5DQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIlc0MEKgkAQBmDFg7Cw +AjuG2hYRifDCvIQ1KlrUB07FHXW3sxH2UfYowfxb9yUVQ/zDcwMw+7MIxEKHSuxWIrbjLMnZ1FM lbAttK3rg7M04yw4iyimtKcGpfS4ETQeZAfxfn3unGVbgcoGOixCTckBOWGdAOVljNT4QKFGfJUH 2JpqSONUbk9tcFC7msZgo9J4GnTQSoueZ03JpSFB0VImpSHvKXJIfwA6PPq3+sPZjq544uwnwABq z8DpDQplbmRzdHJlYW0NCmVuZG9iag0KNzggMCBvYmoNCjw8DQovTGVuZ3RoIDE3Nw0KL0ZpbHRl ciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJMjFUMFAwU9A1VDA2VzC1UEgx5OUq5OUyBgkb KJhaQuSSc3m5nDx5ufTDFYyBCvQ9gDJAyinAWQHE9fRVKCkqTeXl8nRR+P+A+f9/Bob6PwwM8h8Y GPgfMDCwg/AB9g/MB+R/MDfY/2FuqP/D2FD/j7Hh/z9GBqwYaATNMC47QRjkLjAGuhPkVqCb+R+w Q/3AD/SPPNBf9v8YgCY9YP/Py+UKDJRAXi6AAAMAGRWVCA0KZW5kc3RyZWFtDQplbmRvYmoNCjc5 IDAgb2JqDQo8PA0KL0xlbmd0aCAxNTANCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFt DQpIiTIxVjBQMANiY0sFU3OFFENerkJeLmOQqAFIACSVnMvL5eTJy6UfrmBsDKQ8gBJAyinAWQGo XN/TV6GkqDSVl8vTRYGBgf3/fwYGBjAhDyL4QQQ7iGD+z/D/ASOQ+AMi/jH8B6lCEPVAomEoEGCX wh0O9gfYRx8Yob6EEuxw79sDCcb//3m5XIGhGMjLBRBgAL8vpLQNCmVuZHN0cmVhbQ0KZW5kb2Jq DQo4MCAwIG9iag0KPDwNCi9MZW5ndGggMTA3DQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0 cmVhbQ0KSIkyNlUwUABhY0MFU3OFFENerkJeLiMzoIgBSAAklZzLy+XkyculH65gZAakPIASQMop wFkBqFzf01ehpKg0lZfL00WBgYGhHiv+//8/1TADA3ZMTTsg9thjw7xcrsDACOTlAggwAFBTjtUN CmVuZHN0cmVhbQ0KZW5kb2JqDQo4MSAwIG9iag0KPDwNCi9MZW5ndGggMTAyDQovRmlsdGVyIC9G bGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIkyNlEwUDAFYmMgZa6QYsjLVcjLZQQSAQuAGMm5vFxO nrxc+uEKRqZAygMoAaScApwVgMr1PX0VSopKU3m5PF0UGBgY6rHi////Uw0zMGDH1LQDD+blcgUG RiAvF0CAAQCmwp9FDQplbmRzdHJlYW0NCmVuZG9iag0KODIgMCBvYmoNCjw8DQovTGVuZ3RoIDE4 Nw0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJnNA9CsJAEAXgFywCC4tHyFxA YlgDsQpEBVMIWnkATWmhaL05Wo6SI6RMERxno2LjD9h8A/uW/XkTQ2OKaRSRSShOaB9pddTKuGUJ pvdsd9Aqy7UKt2SMjKUkMrL1jGR/mK/ofLoUWuVz4tpjZiDlDhhyC/jcAAOuAY8rvxWCK7hMe1iw DCuUFj38FjnzDwD7hc+3/cS9tHyRPqkCh9/Byn8fNI7Owa4IacKyVgvpc6PVTYABANiZs+0NCmVu ZHN0cmVhbQ0KZW5kb2JqDQo4MyAwIG9iag0KPDwNCi9MZW5ndGggOTgNCi9GaWx0ZXIgL0ZsYXRl RGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiTIxVjBQMAViY3MFU3OFFENerkJeLmMjoIgBSAAklZzLy+Xk yculH65gbASkPIASQMopwFkBqFzf01ehpKg0lZfL00WB4f9/BppjXIAedgMxL5crMDACebkAAgwA wod1dQ0KZW5kc3RyZWFtDQplbmRvYmoNCjg0IDAgb2JqDQo8PA0KL0xlbmd0aCA4NQ0KL0ZpbHRl ciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJMrRQMFAwBWJDYwVTc4UUQ16uQl4ukKABiA+S Sc7l5XLy5OXSD1ewAJIeQHEg5RTgrABUrO/pq1BSVJrKy+XposBALuDlcgVaEMjLBRBgAMogD30N CmVuZHN0cmVhbQ0KZW5kb2JqDQo4NSAwIG9iag0KPDwNCi9MZW5ndGggOTMNCi9GaWx0ZXIgL0Zs YXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiTI2UjBQMAViI0sFU3OFFENerkJeLiMToIgBSAAklZzL y+XkyculH65gZAKkPIASQMopwFkBqFzf01ehpKg0lZfL00WB4f//QYowAC+XK9BPgbxcAAEGAKOz dXYNCmVuZHN0cmVhbQ0KZW5kb2JqDQo4NiAwIG9iag0KPDwNCi9MZW5ndGggMTg1DQovRmlsdGVy IC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSIl80M8KgkAQBnBlA2Fp8QUC5w1U8M8lEKwgD0Gd egDr2KGoW6C92T7KPoJHD+I2gxQiW4f5DXzfnCZOIYCYJoQ4hVMo+FXwKMEkoICq8iJ4XgjuHyFK cG2xwJXvV4DnfrGD++1xFrxYg8W0tthPbd3/sdbdzGhFyqqdm1RZuyCbiU3WLFFPGW1d9STlxM6V HeoM1hN750WyQfurZoy0R1oja8esdM2qQe+j4Bt8/0HwtwADACP9lIINCmVuZHN0cmVhbQ0KZW5k b2JqDQo4NyAwIG9iag0KPDwNCi9MZW5ndGggMTY3DQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4N CnN0cmVhbQ0KSIlU0DEKwlAMBuBXOhQCoUcwN2ilLeJUqAp2EHRyFdTRQdHZHq1H6RE6dijW/6GP 8IZ8gT8hQ/JcUilQ2VKKhVzmTHemzKapDezofGOqaqbkKFmOtsUArdqvBOtJvZPn43Vlqtdi4qkr f0Q+oU/gCBRjaZQ3aJUSdMrM0SsxGJQIjEro+Cg4FkyKsTTKCbSKODrFgN5n8Bn/MG3wxQPTV4AB AF2PjW0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo4OCAwIG9iag0KPDwNCi9MZW5ndGggMTgxDQovRmls dGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSInUkDEKwkAQRf+SIrCweITMBSSGNRCrQFQw haCVB1BLC0XrzdFylBwhZYqQcTbrJWz+wPwZ+O+vLa0op2VGtqC8oFtm9NNo69dibIJ3fRhd1Uan F7JWxkEcGdVpS3Kf1kd6vz53o+sdcRcxM+B4BBIegAX3QMwdEHEb94rbZFTclBNEWMQFaVieGgf+ B/FJfXD3Sz/DiAgbAqXwqgA94w++jQkoeW7I6L30eTb6K8AAiKS2XQ0KZW5kc3RyZWFtDQplbmRv YmoNCjg5IDAgb2JqDQo8PA0KL0xlbmd0aCAxNDgNCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0K c3RyZWFtDQpIiTK2UDBQMAViY1MFU3OFFENerkJeLmMDBRAECoCkknN5uZw8ebn0wxWMDYCUB1AC SDkFOCsAlet7+iqUFJWm8nJ5uigwMMj/Z2BgBGKGeiC2B2J5IOZn+N/AzvD/ARB/AOIfIMzM8P8P EfgHVP0HqP4GfqiZ8lDzgXYx/wfb+/8/XTAvlyswMAJ5uQACDADkVIjfDQplbmRzdHJlYW0NCmVu ZG9iag0KOTAgMCBvYmoNCjw8DQovTGVuZ3RoIDE2OA0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+ DQpzdHJlYW0NCkiJMjFUMFAwBWJjCwVTc4UUQ16uQl4uY2OgiAFIACSVnMvL5eTJy6UfrmBsDKQ8 gBJAyinAWQGoXN/TV6GkqDSVl8vTRYGBgfH/fwYGBnsQIQ8i2OEE83+G/w8YgcQPEPEPTDAAif+k EP8YUYg/IEN/sINMZodbCbIc4oz/cDF+oJIDIHUfQMQPZhjxBwvxjxnTItII7K7n5XIFhmIgLxdA gAEAhPilvw0KZW5kc3RyZWFtDQplbmRvYmoNCjkxIDAgb2JqDQo8PA0KL0xlbmd0aCAyMTgNCi9G aWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiYyQwQqCQBCGRzwIC4uP4LxAqKxSnQQr yENQpx6gOnYo6qyP5qPsI3j0IDvNqNCxLt/Cfv/A/JMlmGCGixTNEvMVXlOtHloZgyLy9eQud63K Sqv4jMbws2fDT3ncIOfj6oCv5/umVbVF6jwiaqAgBxBSDxBQB+ALPLIB6zYcgNrIMQoCakbUP0CS I5lgRIKAYX1GByM40wObAcTAtAZ/Wt6F9dfITCvaCnqZHgROQFDDjOZPAMfHJZ2UGTxqQmkppe1c fzxEJCepp8212vE9T1p9BBgA29/C0Q0KZW5kc3RyZWFtDQplbmRvYmoNCjkyIDAgb2JqDQo8PA0K L0xlbmd0aCA5OA0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJMjFQMFAwBmFz BVNzhRRDXq5CXi5jEwWQOFAAJJWcy8vl5MnLpR+uYGwCpDyAEkDKKcBZAahc39NXoaSoNJWXy9NF gQEI7HES/3+w//8/cgleLldgKAbycgEEGABzwNyGDQplbmRzdHJlYW0NCmVuZG9iag0KOTMgMCBv YmoNCjw8DQovTGVuZ3RoIDEzNQ0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJ MjFWMFAwU9A1VDC2UDA1V0gx5OUq5OUyNgIKGyiYWkDkknN5uZw8ebn0wxWMjYCUB1AGSDkFOCsA 1et7+iqUFJWm8nJ5uigw/P/PMCRx/T8wbqj/x9hg/4exQf4H4wH2B8wPGBjYQfgDAwP/HwYGe7Dq B+z/eblcgQESyMsFEGAAfhB+wQ0KZW5kc3RyZWFtDQplbmRvYmoNCjYgMCBvYmoNCjw8DQovVHlw ZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUxDQovTmFtZSAvRjINCi9GaXJzdENoYXIgMzINCi9MYXN0 Q2hhciAxMjENCi9XaWR0aHMgWzI5MiAwIDAgMCAwIDAgMCAyNzQgMCAwIDAgMCAwIDQzMCAwIDAg DQowIDAgMCAwIDAgMCAwIDAgMCA2MzQgMzYyIDAgMCAwIDAgMCANCjAgNjgyIDAgNjY1IDc1NCA2 MTMgNTc5IDAgMCA0ODEgMCAwIDU3MCA4OTAgMCA3NjcgDQo2NTUgMCA3MjMgNjMxIDYxMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgDQowIDU5NiA2MjkgNTI1IDAgNTkxIDM4MSAwIDYzOCAzMDEgMCAw IDAgOTUwIDYzOCA2MTUgDQo2MjcgMCA0MzIgNTEzIDQxNCA2MzggMCAwIDAgNTczIF0NCi9FbmNv ZGluZyA5NCAwIFINCi9CYXNlRm9udCAvQ0JKQU1LK01TVFQzMWM4NGINCi9Gb250RGVzY3JpcHRv ciAyNiAwIFINCj4+DQplbmRvYmoNCjcgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUg L1R5cGUxDQovTmFtZSAvRjQNCi9FbmNvZGluZyA5NSAwIFINCi9CYXNlRm9udCAvVGltZXMtUm9t YW4NCj4+DQplbmRvYmoNCjggMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUx DQovTmFtZSAvRjYNCi9FbmNvZGluZyA5NSAwIFINCi9CYXNlRm9udCAvSGVsdmV0aWNhDQo+Pg0K ZW5kb2JqDQo5IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUg L0Y4DQovRW5jb2RpbmcgOTUgMCBSDQovQmFzZUZvbnQgL0hlbHZldGljYS1Cb2xkDQo+Pg0KZW5k b2JqDQoxMCAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTENCi9OYW1lIC9G MTANCi9FbmNvZGluZyA5NSAwIFINCi9CYXNlRm9udCAvVGltZXMtQm9sZA0KPj4NCmVuZG9iag0K MTEgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUxDQovTmFtZSAvRjEzDQov Rmlyc3RDaGFyIDANCi9MYXN0Q2hhciAyNTUNCi9XaWR0aHMgWzQwMCA0MDAgNTAwIDQ4MCA0NjAg NTAwIDMyMCA1MDAgMzQwIDM2MCA0NDAgMzIwIDUwMCAzNjAgNDYwIDQ2MCANCjQ2MCA0NjAgNDYw IDQ2MCA0NjAgNDYwIDQ2MCA0NjAgNDYwIDQ2MCA0NjAgNDYwIDQ2MCA0NjAgNDYwIDQ2MCANCjM0 MCAzNjAgNDIwIDY2MCA2NjAgOTQwIDgwMCAyNDAgMzIwIDMyMCA0NjAgNjAwIDM0MCAzNjAgMzQw IDYwMCANCjY2MCA2NjAgNjYwIDY2MCA2NjAgNjYwIDY2MCA2NjAgNjYwIDY2MCAzNDAgMzQwIDYw MCA2MDAgNjAwIDY2MCANCjgyMCA3MjAgNzIwIDc0MCA3ODAgNzIwIDY4MCA3ODAgODIwIDQwMCA2 NDAgODAwIDY0MCA5NDAgNzQwIDgwMCANCjY2MCA4MDAgNzgwIDY2MCA3MDAgNzQwIDcyMCA5NDAg NzgwIDcwMCA2NDAgMzAwIDYwMCAzMDAgNjAwIDUwMCANCjQwMCA1ODAgNjAwIDU4MCA2NDAgNTgw IDM4MCA1ODAgNjgwIDM2MCAzNDAgNjYwIDM0MCAxMDAwIDY4MCA2MjAgDQo2NDAgNjIwIDQ2MCA1 MjAgNDYwIDY2MCA2MDAgODAwIDYwMCA2MjAgNTYwIDMyMCA2MDAgMzIwIDYwMCA0NjAgDQo0NjAg NDYwIDMyMCA2NjAgNTQwIDEwMDAgNDQwIDM4MCA1MDAgMTM2MCA2NjAgMjIwIDEyMjAgNDYwIDQ2 MCA0NjAgDQo0NjAgMzIwIDMyMCA1NDAgNTQwIDQ2MCA1MDAgMTAwMCA0ODAgOTgwIDUyMCAyMjAg OTQwIDQ2MCA0NjAgNzAwIA0KMzQwIDM2MCA2NjAgNjYwIDY2MCA2NjAgNjAwIDYwMCA1MDAgNzQw IDQwMCA0MDAgNjAwIDM2MCA3NDAgNDYwIA0KNDAwIDYwMCAzOTYgMzk2IDQwMCA2NjAgODAwIDM0 MCAzNjAgMzk2IDQwMCA0MDAgOTkwIDk5MCA5OTAgNjYwIA0KNzIwIDcyMCA3MjAgNzIwIDcyMCA3 MjAgMTE0MCA3NDAgNzIwIDcyMCA3MjAgNzIwIDQwMCA0MDAgNDAwIDQwMCANCjc4MCA3NDAgODAw IDgwMCA4MDAgODAwIDgwMCA2MDAgODAwIDc0MCA3NDAgNzQwIDc0MCA3MDAgNjYwIDY2MCANCjU4 MCA1ODAgNTgwIDU4MCA1ODAgNTgwIDg4MCA1ODAgNTgwIDU4MCA1ODAgNTgwIDM2MCAzNjAgMzYw IDM2MCANCjYyMCA2ODAgNjIwIDYyMCA2MjAgNjIwIDYyMCA2MDAgNjIwIDY2MCA2NjAgNjYwIDY2 MCA2MjAgNjQwIDYyMCANCl0NCi9FbmNvZGluZyA5NSAwIFINCi9CYXNlRm9udCAvQm9va21hbi1E ZW1pDQovRm9udERlc2NyaXB0b3IgMjggMCBSDQo+Pg0KZW5kb2JqDQoyMSAwIG9iag0KPDwNCi9U eXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTENCi9OYW1lIC9GMTUNCi9GaXJzdENoYXIgMA0KL0xh c3RDaGFyIDI1NQ0KL1dpZHRocyBbMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMg MzMzIDMzMyAzMzMgMzMzIDMzMyA2MDYgNjA2IA0KNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2 IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IA0KMjUwIDI3OCA0MDIgNTAwIDUw MCA4ODkgODMzIDIyNyAzMzMgMzMzIDQ0NCA2MDYgMjUwIDMzMyAyNTAgMjk2IA0KNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI1MCAyNTAgNjA2IDYwNiA2MDYgNDQ0IA0K NzQ3IDc3OCA2NjcgNzIyIDgzMyA2MTEgNTU2IDgzMyA4MzMgMzg5IDM4OSA3NzggNjExIDEwMDAg ODMzIDgzMyANCjYxMSA4MzMgNzIyIDYxMSA2NjcgNzc4IDc3OCAxMDAwIDY2NyA2NjcgNjY3IDMz MyA2MDYgMzMzIDYwNiA1MDAgDQozMzMgNTAwIDYxMSA0NDQgNjExIDUwMCAzODkgNTU2IDYxMSAz MzMgMzMzIDYxMSAzMzMgODg5IDYxMSA1NTYgDQo2MTEgNjExIDM4OSA0NDQgMzMzIDYxMSA1NTYg ODMzIDUwMCA1NTYgNTAwIDMxMCA2MDYgMzEwIDYwNiA2MDYgDQo2MDYgNjA2IDMzMyA1MDAgNTAw IDEwMDAgNTAwIDUwMCAzMzMgMTAwMCA2MTEgMzg5IDEwMDAgNjA2IDYwNiA2MDYgDQo2MDYgMjc4 IDI3OCA1MDAgNTAwIDYwNiA1MDAgMTAwMCAzMzMgOTk4IDQ0NCAzODkgODMzIDYwNiA2MDYgNjY3 IA0KMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgNjA2IDUwMCAzMzMgNzQ3IDQzOCA1MDAgNjA2IDMz MyA3NDcgMzMzIA0KNDAwIDYwNiAzMDAgMzAwIDMzMyA2MTEgNjQxIDI1MCAzMzMgMzAwIDQ4OCA1 MDAgNzUwIDc1MCA3NTAgNDQ0IA0KNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggMTAwMCA3MjIgNjEx IDYxMSA2MTEgNjExIDM4OSAzODkgMzg5IDM4OSANCjgzMyA4MzMgODMzIDgzMyA4MzMgODMzIDgz MyA2MDYgODMzIDc3OCA3NzggNzc4IDc3OCA2NjcgNjExIDYxMSANCjUwMCA1MDAgNTAwIDUwMCA1 MDAgNTAwIDc3OCA0NDQgNTAwIDUwMCA1MDAgNTAwIDMzMyAzMzMgMzMzIDMzMyANCjU1NiA2MTEg NTU2IDU1NiA1NTYgNTU2IDU1NiA2MDYgNTU2IDYxMSA2MTEgNjExIDYxMSA1NTYgNjExIDU1NiAN Cl0NCi9FbmNvZGluZyA5NSAwIFINCi9CYXNlRm9udCAvUGFsYXRpbm8tQm9sZA0KL0ZvbnREZXNj cmlwdG9yIDI5IDAgUg0KPj4NCmVuZG9iag0KMjIgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1 YnR5cGUgL1R5cGUxDQovTmFtZSAvRjE4DQovRmlyc3RDaGFyIDANCi9MYXN0Q2hhciAyNTUNCi9X aWR0aHMgWzI3MyAyNzMgMjczIDI3MyAyNzMgMjczIDI3MyAyNzMgMjczIDI3MyAyNzMgMjczIDI3 MyAyMjggMjg3IDI4NyANCjI4NyAyODcgMjg3IDI4NyAyODcgMjg3IDI4NyAyODcgMjg3IDI4NyAy ODcgMjg3IDI4NyAyODcgMjg3IDI4NyANCjIyOCAyMjggMjkxIDQ1NiA0NTYgNzI5IDU0NyAxNTcg MjczIDI3MyAzMTkgNDc5IDIyOCAyNzMgMjI4IDIyOCANCjQ1NiA0NTYgNDU2IDQ1NiA0NTYgNDU2 IDQ1NiA0NTYgNDU2IDQ1NiAyMjggMjI4IDQ3OSA0NzkgNDc5IDQ1NiANCjgzMiA1NDcgNTQ3IDU5 MiA1OTIgNTQ3IDUwMSA2MzggNTkyIDIyOCA0MTAgNTQ3IDQ1NiA2ODMgNTkyIDYzOCANCjU0NyA2 MzggNTkyIDU0NyA1MDEgNTkyIDU0NyA3NzQgNTQ3IDU0NyA1MDEgMjI4IDIyOCAyMjggMzg1IDQ1 NiANCjI3MyA0NTYgNDU2IDQxMCA0NTYgNDU2IDIyOCA0NTYgNDU2IDE4MiAxODIgNDEwIDE4MiA2 ODMgNDU2IDQ1NiANCjQ1NiA0NTYgMjczIDQxMCAyMjggNDU2IDQxMCA1OTIgNDEwIDQxMCA0MTAg Mjc0IDIxMyAyNzQgNDc5IDI4NyANCjI4NyAyODcgMTgyIDQ1NiAyNzMgODIwIDQ1NiA0NTYgMjcz IDgyMCA1NDcgMjczIDgyMCAyODcgMjg3IDI4NyANCjI4NyAxODIgMTgyIDI3MyAyNzMgMjg3IDQ1 NiA4MjAgMjczIDgyMCA0MTAgMjczIDc3NCAyODcgMjg3IDU0NyANCjIyOCAyNzMgNDU2IDQ1NiA0 NTYgNDU2IDIxMyA0NTYgMjczIDYwNCAzMDMgNDU2IDQ3OSAyNzMgNjA0IDI3MyANCjMyOCA0Nzkg MjczIDI3MyAyNzMgNDU2IDQ0MCAyMjggMjczIDI3MyAyOTkgNDU2IDY4NCA2ODQgNjg0IDUwMSAN CjU0NyA1NDcgNTQ3IDU0NyA1NDcgNTQ3IDgyMCA1OTIgNTQ3IDU0NyA1NDcgNTQ3IDIyOCAyMjgg MjI4IDIyOCANCjU5MiA1OTIgNjM4IDYzOCA2MzggNjM4IDYzOCA0NzkgNjM4IDU5MiA1OTIgNTky IDU5MiA1NDcgNTQ3IDUwMSANCjQ1NiA0NTYgNDU2IDQ1NiA0NTYgNDU2IDcyOSA0MTAgNDU2IDQ1 NiA0NTYgNDU2IDIyOCAyMjggMjI4IDIyOCANCjQ1NiA0NTYgNDU2IDQ1NiA0NTYgNDU2IDQ1NiA0 NzkgNTAxIDQ1NiA0NTYgNDU2IDQ1NiA0MTAgNDU2IDQxMCANCl0NCi9FbmNvZGluZyA5NSAwIFIN Ci9CYXNlRm9udCAvSGVsdmV0aWNhLU5hcnJvdw0KL0ZvbnREZXNjcmlwdG9yIDMwIDAgUg0KPj4N CmVuZG9iag0KMjMgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUxDQovTmFt ZSAvRjIwDQovRmlyc3RDaGFyIDANCi9MYXN0Q2hhciAyNTUNCi9XaWR0aHMgWzM0MCAzNDAgNDIw IDQ0MCA0NDAgNDYwIDI2MCA0MjAgMzIwIDMyMCAzODAgMzIwIDQyMCAzMDAgNDYwIDQ2MCANCjQ2 MCA0NjAgNDYwIDQ2MCA0NjAgNDYwIDQ2MCA0NjAgNDYwIDQ2MCA0NjAgNDYwIDQ2MCA0NjAgNDYw IDQ2MCANCjMyMCAzMDAgMzgwIDYyMCA2MjAgOTAwIDgwMCAyMjAgMzAwIDMwMCA0NDAgNjAwIDMy MCA0MDAgMzIwIDYwMCANCjYyMCA2MjAgNjIwIDYyMCA2MjAgNjIwIDYyMCA2MjAgNjIwIDYyMCAz MjAgMzIwIDYwMCA2MDAgNjAwIDU0MCANCjgyMCA2ODAgNzQwIDc0MCA4MDAgNzIwIDY0MCA4MDAg ODAwIDM0MCA2MDAgNzIwIDYwMCA5MjAgNzQwIDgwMCANCjYyMCA4MjAgNzIwIDY2MCA2MjAgNzgw IDcwMCA5NjAgNzIwIDY0MCA2NDAgMzAwIDYwMCAzMDAgNjAwIDUwMCANCjM0MCA1ODAgNjIwIDUy MCA2MjAgNTIwIDMyMCA1NDAgNjYwIDMwMCAzMDAgNjIwIDMwMCA5NDAgNjYwIDU2MCANCjYyMCA1 ODAgNDQwIDUyMCAzODAgNjgwIDUyMCA3ODAgNTYwIDU0MCA0ODAgMjgwIDYwMCAyODAgNjAwIDQ2 MCANCjQ2MCA0NjAgMjIwIDYyMCA0MDAgMTAwMCA1NDAgNTQwIDQyMCAxMjgwIDY2MCAyNDAgMTI0 MCA0NjAgNDYwIDQ2MCANCjQ2MCAyMjAgMjIwIDQwMCA0MDAgNDYwIDUwMCAxMDAwIDQ0MCA5ODAg NTIwIDI0MCA5MDAgNDYwIDQ2MCA2NDAgDQozMjAgMzAwIDYyMCA2MjAgNjIwIDYyMCA2MDAgNTIw IDQyMCA3NDAgNDIwIDM2MCA2MDAgNDAwIDc0MCA0NDAgDQo0MDAgNjAwIDM3MiAzNzIgMzQwIDY4 MCA2MDAgMzIwIDMyMCAzNzIgNDIwIDM2MCA5MzAgOTMwIDkzMCA1NDAgDQo2ODAgNjgwIDY4MCA2 ODAgNjgwIDY4MCAxMjYwIDc0MCA3MjAgNzIwIDcyMCA3MjAgMzQwIDM0MCAzNDAgMzQwIA0KODAw IDc0MCA4MDAgODAwIDgwMCA4MDAgODAwIDYwMCA4MDAgNzgwIDc4MCA3ODAgNzgwIDY0MCA2MjAg NjYwIA0KNTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgODYwIDUyMCA1MjAgNTIwIDUyMCA1MjAgMzAw IDMwMCAzMDAgMzAwIA0KNTYwIDY2MCA1NjAgNTYwIDU2MCA1NjAgNTYwIDYwMCA1NjAgNjgwIDY4 MCA2ODAgNjgwIDU0MCA2MjAgNTQwIA0KXQ0KL0VuY29kaW5nIDk1IDAgUg0KL0Jhc2VGb250IC9C b29rbWFuLUxpZ2h0DQovRm9udERlc2NyaXB0b3IgMzEgMCBSDQo+Pg0KZW5kb2JqDQo5NCAwIG9i ag0KPDwNCi9UeXBlIC9FbmNvZGluZw0KL0RpZmZlcmVuY2VzIFsgMC9HMDAgOS9HMDkgMTAvRzBB IDEzL0cwRCAxMjcvRzdGIDEyOC9HODANCl0NCj4+DQplbmRvYmoNCjk1IDAgb2JqDQo8PA0KL1R5 cGUgL0VuY29kaW5nDQovRGlmZmVyZW5jZXMgWyAwL2dyYXZlL2FjdXRlL2NpcmN1bWZsZXgvdGls ZGUvbWFjcm9uL2JyZXZlL2RvdGFjY2VudC9kaWVyZXNpcw0KL3JpbmcvY2VkaWxsYS9odW5nYXJ1 bWxhdXQvb2dvbmVrL2Nhcm9uL2RvdGxlc3NpL2J1bGxldC9idWxsZXQNCi9idWxsZXQvYnVsbGV0 L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0DQovYnVsbGV0L2J1bGxl dC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldA0KIDM5L3F1b3Rlc2lu Z2xlIDk2L2dyYXZlIDEyNy9idWxsZXQvYnVsbGV0L2J1bGxldC9xdW90ZXNpbmdsYmFzZS9mbG9y aW4vcXVvdGVkYmxiYXNlDQovZWxsaXBzaXMvZGFnZ2VyL2RhZ2dlcmRibC9jaXJjdW1mbGV4L3Bl cnRob3VzYW5kL1NjYXJvbi9ndWlsc2luZ2xsZWZ0L09FDQovYnVsbGV0L2J1bGxldC9idWxsZXQv YnVsbGV0L3F1b3RlbGVmdC9xdW90ZXJpZ2h0L3F1b3RlZGJsbGVmdC9xdW90ZWRibHJpZ2h0DQov YnVsbGV0L2VuZGFzaC9lbWRhc2gvdGlsZGUvdHJhZGVtYXJrL3NjYXJvbi9ndWlsc2luZ2xyaWdo dC9vZQ0KL2J1bGxldC9idWxsZXQvWWRpZXJlc2lzL3NwYWNlIDE2NC9jdXJyZW5jeSAxNjYvYnJv a2VuYmFyIDE2OC9kaWVyZXNpcy9jb3B5cmlnaHQNCi9vcmRmZW1pbmluZSAxNzIvbG9naWNhbG5v dC9oeXBoZW4vcmVnaXN0ZXJlZC9tYWNyb24vZGVncmVlL3BsdXNtaW51cy90d29zdXBlcmlvcg0K L3RocmVlc3VwZXJpb3IvYWN1dGUvbXUgMTgzL3BlcmlvZGNlbnRlcmVkL2NlZGlsbGEvb25lc3Vw ZXJpb3Ivb3JkbWFzY3VsaW5lIDE4OC9vbmVxdWFydGVyDQovb25laGFsZi90aHJlZXF1YXJ0ZXJz IDE5Mi9BZ3JhdmUvQWFjdXRlL0FjaXJjdW1mbGV4L0F0aWxkZS9BZGllcmVzaXMvQXJpbmcNCi9B RS9DY2VkaWxsYS9FZ3JhdmUvRWFjdXRlL0VjaXJjdW1mbGV4L0VkaWVyZXNpcy9JZ3JhdmUvSWFj dXRlDQovSWNpcmN1bWZsZXgvSWRpZXJlc2lzL0V0aC9OdGlsZGUvT2dyYXZlL09hY3V0ZS9PY2ly Y3VtZmxleC9PdGlsZGUNCi9PZGllcmVzaXMvbXVsdGlwbHkvT3NsYXNoL1VncmF2ZS9VYWN1dGUv VWNpcmN1bWZsZXgvVWRpZXJlc2lzL1lhY3V0ZQ0KL1Rob3JuL2dlcm1hbmRibHMvYWdyYXZlL2Fh Y3V0ZS9hY2lyY3VtZmxleC9hdGlsZGUvYWRpZXJlc2lzL2FyaW5nDQovYWUvY2NlZGlsbGEvZWdy YXZlL2VhY3V0ZS9lY2lyY3VtZmxleC9lZGllcmVzaXMvaWdyYXZlL2lhY3V0ZQ0KL2ljaXJjdW1m bGV4L2lkaWVyZXNpcy9ldGgvbnRpbGRlL29ncmF2ZS9vYWN1dGUvb2NpcmN1bWZsZXgvb3RpbGRl DQovb2RpZXJlc2lzL2RpdmlkZS9vc2xhc2gvdWdyYXZlL3VhY3V0ZS91Y2lyY3VtZmxleC91ZGll cmVzaXMveWFjdXRlDQovdGhvcm4veWRpZXJlc2lzDQpdDQo+Pg0KZW5kb2JqDQozIDAgb2JqDQo8 PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgMTYgMCBSDQovUmVzb3VyY2VzIDUgMCBSDQovQ29udGVu dHMgNCAwIFINCj4+DQplbmRvYmoNCjE4IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQg MTYgMCBSDQovUmVzb3VyY2VzIDIwIDAgUg0KL0NvbnRlbnRzIDE5IDAgUg0KPj4NCmVuZG9iag0K MTYgMCBvYmoNCjw8DQovVHlwZSAvUGFnZXMNCi9LaWRzIFszIDAgUiAxOCAwIFJdDQovQ291bnQg Mg0KL01lZGlhQm94IFswIDAgNjEyIDc5Ml0NCj4+DQplbmRvYmoNCjk2IDAgb2JqDQo8PA0KL1R5 cGUgL0NhdGFsb2cNCi9QYWdlcyAxNiAwIFINCj4+DQplbmRvYmoNCjk3IDAgb2JqDQo8PA0KL0Ny ZWF0aW9uRGF0ZSAoRDoxOTk5MDQxODE4MTIxNSkNCi9Qcm9kdWNlciAoXDM3NlwzNzdcMDAwQVww MDBjXDAwMHJcMDAwb1wwMDBiXDAwMGFcMDAwdFwwMDAgXDAwMERcMDAwaVwwMDBzXDAwMHRcMDAw aVwwMDBsXDAwMGxcMDAwZVwwMDByXDAwMCBcMDAwM1wwMDAuXDAwMDBcMDAwMVwwMDAgXDAwMGZc MDAwb1wwMDByXDAwMCBcMDAwV1wwMDBpXDAwMG5cMDAwZFwwMDBvXDAwMHdcMDAwcykNCi9BdXRo b3IgKE1haGJ1YnVyIFN5ZWQpDQovQ3JlYXRvciAoSFBQUzQxQS5EUlYgVmVyc2lvbiA0LjEwKQ0K L1RpdGxlIChNaWNyb3NvZnQgV29yZCAtIElTSU1BREU5OS5kb2MpDQo+Pg0KZW5kb2JqDQp4cmVm DQowIDk4DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAxMTU4 MiAwMDAwMCBuDQowMDAwMDQzODgwIDAwMDAwIG4NCjAwMDAwMDYzOTAgMDAwMDAgbg0KMDAwMDAx MTMwNSAwMDAwMCBuDQowMDAwMDM2NTIwIDAwMDAwIG4NCjAwMDAwMzY5NTggMDAwMDAgbg0KMDAw MDAzNzA2NiAwMDAwMCBuDQowMDAwMDM3MTcyIDAwMDAwIG4NCjAwMDAwMzcyODMgMDAwMDAgbg0K MDAwMDAzNzM5MiAwMDAwMCBuDQowMDAwMDIxOTkwIDAwMDAwIG4NCjAwMDAwMjY3OTIgMDAwMDAg bg0KMDAwMDAyNzM5OSAwMDAwMCBuDQowMDAwMDE2ODA4IDAwMDAwIG4NCjAwMDAwNDQwNjEgMDAw MDAgbg0KMDAwMDAxMTYzMyAwMDAwMCBuDQowMDAwMDQzOTY5IDAwMDAwIG4NCjAwMDAwMTI3MDcg MDAwMDAgbg0KMDAwMDAxNjUwNSAwMDAwMCBuDQowMDAwMDM4NjMwIDAwMDAwIG4NCjAwMDAwMzk4 NzAgMDAwMDAgbg0KMDAwMDA0MTEwNiAwMDAwMCBuDQowMDAwMDMxNjkyIDAwMDAwIG4NCjAwMDAw MTY2NzUgMDAwMDAgbg0KMDAwMDAxNjg4OCAwMDAwMCBuDQowMDAwMDE3MjM3IDAwMDAwIG4NCjAw MDAwMjExMTUgMDAwMDAgbg0KMDAwMDAyMTMyMiAwMDAwMCBuDQowMDAwMDIxNTMwIDAwMDAwIG4N CjAwMDAwMjE3MzUgMDAwMDAgbg0KMDAwMDAyMTkzOCAwMDAwMCBuDQowMDAwMDIyMzMwIDAwMDAw IG4NCjAwMDAwMjI0ODQgMDAwMDAgbg0KMDAwMDAyMjcxOCAwMDAwMCBuDQowMDAwMDIyOTk4IDAw MDAwIG4NCjAwMDAwMjMyNzcgMDAwMDAgbg0KMDAwMDAyMzQ0OSAwMDAwMCBuDQowMDAwMDIzNzMx IDAwMDAwIG4NCjAwMDAwMjQwNDIgMDAwMDAgbg0KMDAwMDAyNDMyMSAwMDAwMCBuDQowMDAwMDI0 NTExIDAwMDAwIG4NCjAwMDAwMjQ2OTAgMDAwMDAgbg0KMDAwMDAyNDg2OCAwMDAwMCBuDQowMDAw MDI1MTMzIDAwMDAwIG4NCjAwMDAwMjUzOTEgMDAwMDAgbg0KMDAwMDAyNTcwMiAwMDAwMCBuDQow MDAwMDI1OTk2IDAwMDAwIG4NCjAwMDAwMjYzMjQgMDAwMDAgbg0KMDAwMDAyNjQ5OCAwMDAwMCBu DQowMDAwMDI2NzQwIDAwMDAwIG4NCjAwMDAwMjcwMjMgMDAwMDAgbg0KMDAwMDAyNzA5MSAwMDAw MCBuDQowMDAwMDI3MTMwIDAwMDAwIG4NCjAwMDAwMjczNDcgMDAwMDAgbg0KMDAwMDAyNzc2OCAw MDAwMCBuDQowMDAwMDI3OTMxIDAwMDAwIG4NCjAwMDAwMjgxNTIgMDAwMDAgbg0KMDAwMDAyODMy OCAwMDAwMCBuDQowMDAwMDI4NjEwIDAwMDAwIG4NCjAwMDAwMjg3OTUgMDAwMDAgbg0KMDAwMDAy ODk3NCAwMDAwMCBuDQowMDAwMDI5Mjc1IDAwMDAwIG4NCjAwMDAwMjk1MzIgMDAwMDAgbg0KMDAw MDAyOTgyNSAwMDAwMCBuDQowMDAwMDMwMTIyIDAwMDAwIG4NCjAwMDAwMzAzNDggMDAwMDAgbg0K MDAwMDAzMDUyNCAwMDAwMCBuDQowMDAwMDMwNjk0IDAwMDAwIG4NCjAwMDAwMzA4OTUgMDAwMDAg bg0KMDAwMDAzMTE5MCAwMDAwMCBuDQowMDAwMDMxNDA4IDAwMDAwIG4NCjAwMDAwMzE2NDAgMDAw MDAgbg0KMDAwMDAzMjAyNiAwMDAwMCBuDQowMDAwMDMyMTg2IDAwMDAwIG4NCjAwMDAwMzI0NDYg MDAwMDAgbg0KMDAwMDAzMjY0MiAwMDAwMCBuDQowMDAwMDMyOTEzIDAwMDAwIG4NCjAwMDAwMzMx NzIgMDAwMDAgbg0KMDAwMDAzMzQwNCAwMDAwMCBuDQowMDAwMDMzNTkzIDAwMDAwIG4NCjAwMDAw MzM3NzcgMDAwMDAgbg0KMDAwMDAzNDA0NiAwMDAwMCBuDQowMDAwMDM0MjI1IDAwMDAwIG4NCjAw MDAwMzQzOTEgMDAwMDAgbg0KMDAwMDAzNDU2NSAwMDAwMCBuDQowMDAwMDM0ODMyIDAwMDAwIG4N CjAwMDAwMzUwODEgMDAwMDAgbg0KMDAwMDAzNTM0NCAwMDAwMCBuDQowMDAwMDM1NTc0IDAwMDAw IG4NCjAwMDAwMzU4MjQgMDAwMDAgbg0KMDAwMDAzNjEyNCAwMDAwMCBuDQowMDAwMDM2MzAzIDAw MDAwIG4NCjAwMDAwNDIzNDQgMDAwMDAgbg0KMDAwMDA0MjQ0OCAwMDAwMCBuDQowMDAwMDQ0MTU4 IDAwMDAwIG4NCjAwMDAwNDQyMTUgMDAwMDAgbg0KdHJhaWxlcg0KPDwNCi9TaXplIDk4DQovUm9v dCA5NiAwIFINCi9JbmZvIDk3IDAgUg0KL0lEIFs8YTBjNjAxNTIyOGZlZTg4MzRkZjFjMzNjNjJj ZTgxNDc+PGEwYzYwMTUyMjhmZWU4ODM0ZGYxYzMzYzYyY2U4MTQ3Pl0NCj4+DQpzdGFydHhyZWYN CjQ0NTcwDQolJUVPRg0K --=====================_924499579==_ Content-Type: text/plain; charset="us-ascii" ******************************** Dr. Mahbubur Rahman Syed Department of Electrical Engineering, EERoom 101 North Dakota State University Fargo, ND 58105, USA Email: msyed@badlands.nodak.edu Phone: (701) 231 7689=20 Fax: (701) 231 8677 ********************************=20 --=====================_924499579==_-- From rem-conf Sun Apr 18 19:27:35 1999 From rem-conf-request@es.net Sun Apr 18 19:27:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Z3kX-0001zm-00; Sun, 18 Apr 1999 19:25:29 -0700 Received: from emulive-23.emulive.com (emuweb.emulive.com) [207.253.50.151] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Z3kV-0001zU-00; Sun, 18 Apr 1999 19:25:27 -0700 Received: from user12345 (stat245.jcs-canada.com [207.253.50.245]) by emuweb.emulive.com (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id VAA00135; Sun, 18 Apr 1999 21:57:12 -0400 Date: Sun, 18 Apr 1999 21:57:12 -0400 From: Emulive promotions To: Subject: STREAMING VIDEO SOFTWARE CLEARANCE SALE Message-Id: Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list YOUR OWN VIDEO BROADCAST STATION FOR AS LOW AS $199! ALL NECESSARY SOFTWARE INCLUDED! EASY TO INSTALL AND USE! Dear Video Streaming Enthusiast, I would like to take this opportunity to introduce you to Emulive Imaging Corporation. Emulive is a software development company based in Montreal, Canada. Our product suite allows you to CREATE, MANAGE, BROADCAST and PLAY live and/or pre-recorded video to an unlimited number of viewers over the internet, intranets and extranets. Emulive's solutions are compatible with all types of TCP/IP connections including (but not limited to) modem, ISDN, xDSL, T1, T3 and Ethernet. Our playerless java solution offers your audience the ability to immediately view broadcasts within any popular web browser from any platform without having to install a player beforehand. Unlike competing products, our solutions offer high performance on all but the slowest of PC's, using 32-Bit Windows platforms including 95, 98 and NT. WE'RE CLEARING OUR INVENTORY! We are excited to announce a massive clearance sale to make room in our inventory for the much-anticipated release of version 4. For a limited time, we are now offering three Video Broadcasters Kit (VBK) promotions. VBK PRODUCT HIGHLIGHTS The Video Broadcasters Kit consists of two award winning products by Emulive Imaging Video Producer - Real-time video encoding, editing and effects at up to 30 frames per second - Screenscrape feature allows you to use your PC screen as a camera input - Runs on any Windows platform and uses Video for Windows compatible devices for camera input Server - Supports 20 incoming live video feeds and unlimited number of pre-recorded files - Multi-level security features - Integrated Java broadcast viewer with Java chat - Chat server, directory client - Unicast and multicast streaming capabilities - Centralized management of all server content - Complete logging features for audit trails and referrals - Upgradable to 5, 10, 25, 50, 100, 250, 500 and 1000 simultaneous users - Upgradable to the Commerce Edition/Merchant Server which allows PAY PER VIEW VBK PROMOTIONS Over $500 off on every kit! 1) Starter VBK Includes - 1x Video Producer - 1x 5 user standard server Allows 5 simultaneous viewers to see your video broadcast $199.00 US 2) Intermediate VBK Includes - 1x Video Producer - 1x 25 user standard server Allows 25 simultaneous viewers to see your video broadcast $499.00 US 3) Professional VBK Includes - 1x Video Producer - 1x 50 user standard server Allows 50 simultaneous viewers to see your video broadcast $999.00 US EACH VBK KIT INCLUDES - Immediate product delivery via the internet - Retail CD-ROM package via snail-mail - An Emulive T-Shirt - Product specification sheets, info on how to be a reseller and more - 5 minute set-up, zero maintenance - High quality web video at a configurable frame rate - Rich on-line documentation with context sensitive help - FREE major point revision upgrades for registered users - 90-day free technical support - 30 day money-back guarantee TRY BEFORE YOU BUY Server and Video Producer are immediately downloadable from our website. These shareware releases will allow you to build a fully functional system that will operate an unlimited number of times at 30 minutes per operating session. DOWNLOAD SERVER AND VIDEO PRODUCER http://www.emulive.com/downloads LEARN MORE ABOUT SERVER AND VIDEO PRODUCER http://www.emulive.com/products/ HOW TO BUILD YOUR OWN STREAMING VIDEO SOLUTION The applications are almost limitless. We have customers using our VBK for purposes such as security, training, conferencing, medical imaging, day care monitoring, nanny monitoring and event broadcasting. Find out more on our website at http://www.emulive.com/products/solutions/overview.htm ORDER THE VBK WITH YOUR CREDIT CARD Once you've had a chance to evaluate the Video Broadcaster Kit, contact Randee Fagen at (514) 954-1919 ext. 103, toll free at 877-EMULIVE, or by email at randee@emulive.com. To receive license keys that will unlock the software, we accept payment by Mastercard, Visa, American Express and wire transfer. Once your order has cleared, we'll contact you with additional instructions on how to unlock the software. IMPULSE BUYERS If you can't wait, you can order and download a fully licensed copy of our standard Starter Kit for $399 USD via Digital River. The download is immediate, the license is immediately active. To buy now, click the following link: http://www.digitalriver.com/dr/v2/ec_MAIN.Entry17c?CID=0&SID=1939&SP=10007&PN=5&PID=132693 WHAT OTHERS SAY We're often told we're 'one of the best kept secrets on the internet'. Our customers love us, and we love 'em right back. Don't just take our word for it though... "...these are four of the most robust network video broadcasting tools I have worked with." Quoted in a two page page review of Server v3.x, Video Producer, freeware Active Theatre client and freeware Theatre Xpresso Java client. Brian Gallagher of WindowsNT Magazine, April 1999, page 149. http://www.winntmag.com/Magazine/EReprint.cfm?ArticleID=5065 "...Emulive products offered were exactly what we were looking for. The products are intuitive, easy to use, easy to implement and monitor, and most of all... no plugins required for the end user. We were impressed with Emulive's commitment to customer service." Michael Owens, Mistral Design Group, Inc. "I currently use Emulive Server 24 hours a day, 7 days a week. It is by far the most reliable software I have ever used. There hasn't been one crash or even a second of lost time with this package! The video output quality is excellent. Emulive's customer service is friendly, responsive and helpful." Sean Breeden, WebWorx Inc. Don’t delay! Impress your friends and co-workers with your technical savvy and show then how they can jump on the broadcast bandwagon as well! Sincerely, Randee Fagen Sales Manager Emulive Imaging Corporation a division of JCS Canada Inc. est 1996 481 Viger Street West, Suite 400 Montreal, Quebec, Canada H2Z 1G6 tel 514-954-1919 fax 514-954-9779 toll free 1-877-EMULIVE Network Alive! From rem-conf Sun Apr 18 20:48:03 1999 From rem-conf-request@es.net Sun Apr 18 20:48:02 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Z4zb-00039q-00; Sun, 18 Apr 1999 20:45:07 -0700 Received: from mail.gmd.de [129.26.8.90] by mail1.es.net with esmtp (Exim 1.81 #2) id 10Z4zZ-00039g-00; Sun, 18 Apr 1999 20:45:06 -0700 Received: (from mayer@localhost) by mail.gmd.de (8.8.8/8.8.8) id FAA01025; Mon, 19 Apr 1999 05:45:03 +0200 (MET DST) Date: Mon, 19 Apr 1999 05:45:03 +0200 (MET DST) From: Hans Mayer Message-Id: <199904190345.FAA01025@mail.gmd.de> To: rem-conf@es.net, schulzrinne@cs.columbia.edu Subject: Re: Shared web browsing X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Any recommendations for a tool that allows "guided web tours" or >"shared/joint web browsing", where the URLs viewed by, say, the >instructor guide the behavior of other web browsers? I remember such a >tool, written in France, being discussed for one of the early WWW >conferences, but can't find a ready reference. Maybe what you're looking for is the Amaya/Jigsaw combo from w3.org. At least that is my understanding but maybe I'm wrong (wouldn't be the first time :) ). To fully support joint editing/browsing needs support from the server and the above seem to support it but I didn't come around to fully in- stall and test it (there's too much other business and they push me into a direction I didn't want to go back: ITU / ISDN / etc - ick). Kind regards, Hans From rem-conf Sun Apr 18 22:50:57 1999 From rem-conf-request@es.net Sun Apr 18 22:50:56 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Z6sU-0004tT-00; Sun, 18 Apr 1999 22:45:54 -0700 Received: from pop3.tu-dresden.de [141.30.2.83] by mail1.es.net with smtp (Exim 1.81 #2) id 10Z6sT-0004tJ-00; Sun, 18 Apr 1999 22:45:54 -0700 Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP); Mon, 19 Apr 1999 07:38:50 +0200 Received: from rncmm2.urz.tu-dresden.de by rmail with SMTP (IC-PP); Mon, 19 Apr 1999 07:37:58 +0200 Received: from localhost (fleck@localhost) by rncmm2.urz.tu-dresden.de (8.8.8+Sun/8.8.8) with SMTP id HAA27415; Mon, 19 Apr 1999 07:45:41 +0200 (MET DST) X-Authentication-Warning: rncmm2.urz.tu-dresden.de: fleck owned process doing -bs Date: Mon, 19 Apr 1999 07:45:40 +0200 (MET DST) From: Christoph Fleck X-Sender: fleck@rncmm2.urz.tu-dresden.de Reply-To: Multimedia Referenzzentrum To: Henning Schulzrinne cc: rem-conf@es.net Subject: Re: Shared web browsing In-Reply-To: <371A0700.D5477A6C@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 > Any recommendations for a tool that allows "guided web tours" or > "shared/joint web browsing", where the URLs viewed by, say, the > instructor guide the behavior of other web browsers? I remember such a > tool, written in France, being discussed for one of the early WWW > conferences, but can't find a ready reference. You maybe looking for webconf (webcanal): http://monet.inria.fr/doc/man/webconf.html On windows you probably have to change the sdr-plugin (sorry, only in german): http://www-mm.urz.tu-dresden.de/FAQ/#sdr-tool Rgds, Christoph Fleck ,------------------------------------------------------------------. | Referenzzentrum fuer multimediale Teledienste (MMRZ), TU Dresden | | Dr. Klaus Koehler, Christoph Fleck | | e-mail: mmt-ref@tu-dresden.de Tel.: 0351 / 463 5653 | | WWW: http://www-mm.urz.tu-dresden.de (GERMANY) | `------------------------------------------------------------------' From rem-conf Mon Apr 19 07:04:36 1999 From rem-conf-request@es.net Mon Apr 19 07:04:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ZEXC-0001pf-00; Mon, 19 Apr 1999 06:56:26 -0700 Received: from burdell.cc.gatech.edu [130.207.3.207] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10ZEXB-0001pV-00; Mon, 19 Apr 1999 06:56:25 -0700 Received: from ibis.cc.gatech.edu (ammar@ibis.cc.gatech.edu [130.207.8.101]) by burdell.cc.gatech.edu (8.9.1/8.9.1) with ESMTP id JAA06291; Mon, 19 Apr 1999 09:56:23 -0400 (EDT) Received: (from ammar@localhost) by ibis.cc.gatech.edu (8.9.1/8.9.1) id JAA14327; Mon, 19 Apr 1999 09:56:23 -0400 (EDT) From: ammar@cc.gatech.edu (Mostafa Ammar) Message-Id: <199904191356.JAA14327@ibis.cc.gatech.edu> Subject: Re: Shared web browsing To: schulzrinne@cs.columbia.edu (Henning Schulzrinne) Date: Mon, 19 Apr 1999 09:56:22 -0400 (EDT) Cc: rem-conf@es.net In-Reply-To: <371A0700.D5477A6C@cs.columbia.edu> from "Henning Schulzrinne" at Apr 18, 99 12:23:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning: A couple of years ago we built a "Multicast Web Touring system" that uses a rel. mcast protocol to share web pages. You can find our code in www.cc.gatech.edu/computing/Telecomm/mwTour This is not a "production" system though and uses our SCE protocol We have Solaris and Windows implementations. Also the IRI (remote instruction) system built at Old Dominion University has a web sharing/touring application through sharing of X Windows interactions. Mostafa > >Any recommendations for a tool that allows "guided web tours" or >"shared/joint web browsing", where the URLs viewed by, say, the >instructor guide the behavior of other web browsers? I remember such a >tool, written in France, being discussed for one of the early WWW >conferences, but can't find a ready reference. Powwow has something like >that, but only for Windows and as part of a closed package. imeet.com >offers a commercial service along these lines, paid by the hour. Another >one I found is a Java class at >http://cdo.weblinq.com/~tiger/code/java/Controller/index.html, but there >must be better solutions. > >Thanks. >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > ================================================================= Mostafa Ammar Phone:(404)894-3292 Professor Fax: (404)385-0332 College of Computing E-mail: ammar@cc.gatech.edu Georgia Institute of Technology Atlanta, GA 30332 WWW:http://www.cc.gatech.edu/fac/Mostafa.Ammar ================================================================= From rem-conf Mon Apr 19 07:38:02 1999 From rem-conf-request@es.net Mon Apr 19 07:38:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ZF73-0002fS-00; Mon, 19 Apr 1999 07:33:29 -0700 Received: from clarinet.u-strasbg.fr [130.79.75.86] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ZF72-0002fH-00; Mon, 19 Apr 1999 07:33:28 -0700 Received: from dpt-info.u-strasbg.fr (videonet.u-strasbg.fr [130.79.75.80]) by clarinet.u-strasbg.fr (8.9.0/8.9.0) with ESMTP id QAA09943 for ; Mon, 19 Apr 1999 16:33:25 +0200 (MET DST) Message-ID: <371B3EB5.523B0DC2@dpt-info.u-strasbg.fr> Date: Mon, 19 Apr 1999 16:33:25 +0200 From: David PATE X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: fr,en MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: Shared web browsing References: <371A0700.D5477A6C@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning Schulzrinne wrote: > > Any recommendations for a tool that allows "guided web tours" or > "shared/joint web browsing", where the URLs viewed by, say, the > instructor guide the behavior of other web browsers? I remember such a > tool, written in France, being discussed for one of the early WWW > conferences, but can't find a ready reference. Perharps, you want to talk about mMosaic: http://sig.enst.fr/~dauphin/mMosaic/index-uk.html > Powwow has something like > that, but only for Windows and as part of a closed package. imeet.com > offers a commercial service along these lines, paid by the hour. Another > one I found is a Java class at > http://cdo.weblinq.com/~tiger/code/java/Controller/index.html, but there > must be better solutions. > > Thanks. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- DAVID ----- ---------------------------------------------------------------------- David PATE' ==>> http://dpt-info.u-strasbg.fr/~pate From rem-conf Mon Apr 19 08:06:53 1999 From rem-conf-request@es.net Mon Apr 19 08:06:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ZFaF-0003c2-00; Mon, 19 Apr 1999 08:03:39 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ZFaD-0003bo-00; Mon, 19 Apr 1999 08:03:37 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.8+Sun/8.8.7) with SMTP id LAA17582; Mon, 19 Apr 1999 11:03:23 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id LAA22014; Mon, 19 Apr 1999 11:04:22 -0400 Date: Mon, 19 Apr 1999 11:04:22 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199904191504.LAA22014@billings.csb> To: rem-conf@es.net, schulzrinne@cs.columbia.edu Subject: Re: Shared web browsing Cc: Peter.Parnes@cdt.luth.se, Tie.Liao@inria.fr, edburns@sgi.com, rodgers@billings.nlm.nih.gov X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Henning, There have been at least three attempts at "webcasting" tools that I am aware of, fostered by the Int. WWW Conference series while I was still active in it: 1) Webcast, a quick hack by Ed Burnsm then a grad. student at NCSA, this was tied in with a hacked version of the Mosaic web client. It was used at WWW3 in Darmstadt in 1995, and I believe was the first attempt to use multicasting in the context of the Web: http://www.ncsa.uiuc.edu/SDG/Software/XMosaic/CCI/webcast.html Ed is at SGI now if you want more information. 2) WebCanal from Tie Liao at INRIA (I think this is the French package you are thinking of, though there is also the mMosaic package from Dauphin); it uses a lightweight form of RMP, LRMP: http://monet.inria.fr/ it was used and presented at WWW5 in Paris in May 1996. 3) mWeb by Peter Parnes, also used and presented at WWW5, is part of the larger "mStar" suite of Java multicast tools: http://www.cdt.luth.se/~peppar/progs/ mStar has been spun off to a new commercial venture, Marratech: http://www.marratech.com/ There are other multicast-based web tools, referenced in the fine Merit list of multicast tools at: http://www.merit.edu/~mbone/index/titles.html many of which were early experiments and are no longer available. I still think this technical marriage holds great promise, and am eager to hear of any other efforts in the area. Cheerio, Rick Rodgers > From rem-conf-request@es.net Sun Apr 18 12:47:36 1999 > Sender: hgs@cs.columbia.edu > Date: Sun, 18 Apr 1999 12:23:28 -0400 > From: Henning Schulzrinne > Organization: Columbia University, Dept. of Computer Science > X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) > X-Accept-Language: en > MIME-Version: 1.0 > To: rem-conf@es.net > Subject: Shared web browsing > Content-Transfer-Encoding: 7bit > X-Mailing-List: > X-Loop: rem-conf@es.net > > Any recommendations for a tool that allows "guided web tours" or > "shared/joint web browsing", where the URLs viewed by, say, the > instructor guide the behavior of other web browsers? I remember such a > tool, written in France, being discussed for one of the early WWW > conferences, but can't find a ready reference. Powwow has something like > that, but only for Windows and as part of a closed package. imeet.com > offers a commercial service along these lines, paid by the hour. Another > one I found is a Java class at > http://cdo.weblinq.com/~tiger/code/java/Controller/index.html, but there > must be better solutions. > > Thanks. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > From rem-conf Mon Apr 19 08:17:39 1999 From rem-conf-request@es.net Mon Apr 19 08:17:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ZFkr-0004H4-00; Mon, 19 Apr 1999 08:14:37 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ZFkq-0004Fd-00; Mon, 19 Apr 1999 08:14:36 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA09859; Mon, 19 Apr 1999 11:14:02 -0400 (EDT) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA17215; Mon, 19 Apr 1999 11:14:00 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <371B4837.B52CC14B@cs.columbia.edu> Date: Mon, 19 Apr 1999 11:13:59 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "R. P. Channing Rodgers, M.D." CC: rem-conf@es.net, Peter.Parnes@cdt.luth.se, Tie.Liao@inria.fr, edburns@sgi.com, rodgers@billings.nlm.nih.gov Subject: Re: Shared web browsing References: <199904191504.LAA22014@billings.csb> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm gathering a list at http://www.cs.columbia.edu/~hgs/rtp/shared.html, to be reorganized once I have a better idea of what's out there. It seems like all these tools distribute the HTML, gif's etc. rather than send around the URL, with local retrieval. Depending on what's in the caches along the way, this may not be the most efficient approach (and also raises copyright issues for some material which cannot be shared that way). Are there any applications that just send around URLs and let the local web browser do the retrieval? This is obviously fairly trivial - the hard part would seem to be to get Netscape or IE to tell an external application what is being browsed... -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Apr 19 08:17:40 1999 From rem-conf-request@es.net Mon Apr 19 08:17:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ZFlA-0004Ha-00; Mon, 19 Apr 1999 08:14:56 -0700 Received: from tyr.unik.no [193.156.96.166] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ZFl9-0004HP-00; Mon, 19 Apr 1999 08:14:55 -0700 Received: from unik.no (hugin.unik.no [193.156.96.102]) by tyr.unik.no (8.8.5/8.8.5) with ESMTP id RAA14170; Mon, 19 Apr 1999 17:14:04 +0200 (MET DST) Sender: plageman@unik.no Message-ID: <371B481F.301E1569@unik.no> Date: Mon, 19 Apr 1999 17:13:35 +0200 From: Thomas Plagemann Organization: University of Oslo X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: rem-conf@es.net Subject: Re: Shared web browsing References: <371A0700.D5477A6C@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning Schulzrinne wrote: > > Any recommendations for a tool that allows "guided web tours" or > "shared/joint web browsing", where the URLs viewed by, say, the > instructor guide the behavior of other web browsers? I remember such a > tool, written in France, being discussed for one of the early WWW > conferences, but can't find a ready reference. Powwow has something like > that, but only for Windows and as part of a closed package. imeet.com > offers a commercial service along these lines, paid by the hour. Another > one I found is a Java class at > http://cdo.weblinq.com/~tiger/code/java/Controller/index.html, but there > must be better solutions. > > Thanks. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs You might be interested in the CoBrow project: http://www.cobrow.com/pages/ Best regards, -- Thomas Plagemann UNIK - Center for Technology at Kjeller University of Oslo WWW: http://www.unik.no/~plageman From rem-conf Mon Apr 19 08:20:05 1999 From rem-conf-request@es.net Mon Apr 19 08:20:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ZFpd-0004f9-00; Mon, 19 Apr 1999 08:19:33 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ZFpc-0004er-00; Mon, 19 Apr 1999 08:19:32 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.8+Sun/8.8.7) with SMTP id LAA18562; Mon, 19 Apr 1999 11:19:27 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id LAA22056; Mon, 19 Apr 1999 11:20:26 -0400 Date: Mon, 19 Apr 1999 11:20:26 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199904191520.LAA22056@billings.csb> To: rodgers@nlm.nih.gov, schulzrinne@cs.columbia.edu Subject: Re: Shared web browsing Cc: rem-conf@es.net, Peter.Parnes@cdt.luth.se, Tie.Liao@inria.fr, edburns@sgi.com, rodgers@billings.nlm.nih.gov X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From schulzrinne@cs.columbia.edu Mon Apr 19 11:15:03 1999 > > I'm gathering a list at > http://www.cs.columbia.edu/~hgs/rtp/shared.html, to be reorganized once Thanks, this will be most helpful to all! > I have a better idea of what's out there. > > It seems like all these tools distribute the HTML, gif's etc. rather > than send around the URL, with local retrieval. Depending on what's in > the caches along the way, this may not be the most efficient approach > (and also raises copyright issues for some material which cannot be > shared that way). Are there any applications that just send around URLs > and let the local web browser do the retrieval? This is obviously fairly > trivial - the hard part would seem to be to get Netscape or IE to tell > an external application what is being browsed... > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs No, in our discussions we always kept a clear distinction between sending URLs and sending content --the former obviously being a much lighter-weight affair (though still presenting scaling issues for the server(s) specified by the URL, should it be hit with a zillion concurrent requests). I believe that at least one (webcast, and perhaps one or both of the other) tools I alluded to allowed you to multicast either content or simply the URLs... Cheerio, Rick Rodgers From rem-conf Mon Apr 19 08:44:32 1999 From rem-conf-request@es.net Mon Apr 19 08:44:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ZGBt-0006Ln-00; Mon, 19 Apr 1999 08:42:33 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10ZGBs-0006LX-00; Mon, 19 Apr 1999 08:42:32 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 19 Apr 1999 16:41:20 +0100 To: Henning Schulzrinne cc: "R. P. Channing Rodgers, M.D." , rem-conf@es.net, Peter.Parnes@cdt.luth.se, Tie.Liao@inria.fr, edburns@sgi.com, rodgers@billings.nlm.nih.gov, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Shared web browsing In-reply-to: Your message of "Mon, 19 Apr 1999 11:13:59 EDT." <371B4837.B52CC14B@cs.columbia.edu> Date: Mon, 19 Apr 1999 16:41:19 +0100 Message-ID: <1312.924536479@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <371B4837.B52CC14B@cs.columbia.edu>, Henning Schulzrinne typed: >>I'm gathering a list at >>http://www.cs.columbia.edu/~hgs/rtp/shared.html, to be reorganized once >>I have a better idea of what's out there. neat - useful thanks! >>It seems like all these tools distribute the HTML, gif's etc. rather >>than send around the URL, with local retrieval. Depending on what's in >>the caches along the way, this may not be the most efficient approach >>(and also raises copyright issues for some material which cannot be >>shared that way). Are there any applications that just send around URLs >>and let the local web browser do the retrieval? This is obviously fairly >>trivial - the hard part would seem to be to get Netscape or IE to tell >>an external application what is being browsed... what would be really interesting would be a hybrid approach - since HTTP lets you know the size of objects (and maybe future URN schemes might add hints too) and we might integrate this with moedia data via SIP/SAP/SDP too, you could choose 1/ whether to multicast the URL and fetch via web 2/ whether to multicast the content 3/ whether to multicast the content to caches and redirect the browsers to caches 4/ any hybrid or multilevel version of the above accounting for lack of ip multicast in any part along the way as with net news multicast, since we have a range facility in HTTP, you dont need to build an end2end reliable multicast servioce (thoguh yo udo need to address congestion control) since anyone missing pieces can request them from the "next level up" - the latter scheme could sue SRM like implosion avoidance too... a neat problem to architect a few PhD solutions to..... cheers jon From rem-conf Mon Apr 19 09:00:56 1999 From rem-conf-request@es.net Mon Apr 19 09:00:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ZGRc-0007Dn-00; Mon, 19 Apr 1999 08:58:48 -0700 Received: from enst.enst.fr [137.194.2.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ZGRb-0007Bu-00; Mon, 19 Apr 1999 08:58:47 -0700 Received: from raven.enst.fr (viper.enst.fr [137.194.130.2]) by enst.enst.fr (8.9.1a/8.9.1) with ESMTP id RAA14922 for ; Mon, 19 Apr 1999 17:58:36 +0200 (MET DST) Received: from tomcat.enst.fr (tomcat.enst.fr [137.194.230.17]) by raven.enst.fr (8.9.1a/8.9.1) with SMTP id RAA05627 for ; Mon, 19 Apr 1999 17:51:55 +0200 (MET DST) Received: by tomcat.enst.fr (SMI-8.6/SMI-SVR4) id RAA03504; Mon, 19 Apr 1999 17:51:41 +0200 Date: Mon, 19 Apr 1999 17:51:41 +0200 From: dauphin@sig.enst.fr (Gilles Dauphin) Message-Id: <199904191551.RAA03504@tomcat.enst.fr> To: rem-conf@es.net Subject: Re: Shared web browsing X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From rem-conf-request@es.net Mon Apr 19 16:54 MET 1999 > > Henning Schulzrinne wrote: > > > > Any recommendations for a tool that allows "guided web tours" or > > "shared/joint web browsing", where the URLs viewed by, say, the > > instructor guide the behavior of other web browsers? I remember such a > > tool, written in France, being discussed for one of the early WWW > > conferences, but can't find a ready reference. > > Perharps, you want to talk about mMosaic: > http://sig.enst.fr/~dauphin/mMosaic/index-uk.html The last stable (hum!) multicast release is mMosaic.3.2.0. Some info are at: http://tsi.enst.fr/~dauphin/mMosaic/old/index.html Best regards, Gilles From rem-conf Tue Apr 20 04:58:49 1999 From rem-conf-request@es.net Tue Apr 20 04:58:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ZYqW-0002ym-00; Tue, 20 Apr 1999 04:37:44 -0700 Received: from dram.scran.ac.uk (scran.ac.uk) [129.215.171.143] by mail1.es.net with smtp (Exim 1.81 #2) id 10ZYqT-0002yY-00; Tue, 20 Apr 1999 04:37:42 -0700 Received: from kjyyf by scran.ac.uk (SMI-8.6/SMI-SVR4) id MAA22257; Tue, 20 Apr 1999 12:31:40 +0100 Message-Id: <199904201131.MAA22257@scran.ac.uk> From: "Rob" Subject: WATCH YOUR PROFITS INCREASE 30-50%! To: speclist673d@music.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Tue, 20 Apr 1999 07:12:53 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list START ACCEPTING CREDIT CARDS & WATCH YOUR PRO=46ITS INCREASE 30-50%! WE SPECIALIZE IN HELPING: * INTERNET * STORE=46RONT * HOMEBASED OR * MAIL ORDER BUSINESSES APPLY BE=46ORE APRIL 29, 1999 AND RECEIVE: * NO APPLICATION =46EE * NO PROGRAMMING =46EE YOUR TOTAL START UP COST IS ONLY $9.95! CALL 1-888-264-9272 (BUSINESS HOURS: 9AM -6PM MST) Remove at: mailto:pp21t@glay.org?subject=3Dremove From rem-conf Tue Apr 20 09:47:37 1999 From rem-conf-request@es.net Tue Apr 20 09:47:36 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ZdYy-00069O-00; Tue, 20 Apr 1999 09:39:56 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ZdYx-00069E-00; Tue, 20 Apr 1999 09:39:55 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id JAA08235; Tue, 20 Apr 1999 09:39:53 -0700 (PDT) Message-Id: <3.0.3.32.19990420093953.00af5b70@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 20 Apr 1999 09:39:53 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 4/21 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar UC Common Authentication Project Wednesday April 21, 1999, 1:00-2:30 p.m. 405 Soda Hall Please note the time frame of the seminar series has changed!! Vance Vaughn Information Systems and Technology, University of California at Berkeley The University of California is engaged in an ambitious project to provide digital credentials to everyone associated with UC including students, faculty, staff, and other members of the university community. I will briefly describe: The underlying technology (e.g., public key/private key encryption, certificates, and PKI) History of the project to date The architecture Current status of the project Some open problems The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Apr 20 13:28:39 1999 From rem-conf-request@es.net Tue Apr 20 13:28:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10Zh4T-0000va-00; Tue, 20 Apr 1999 13:24:41 -0700 Received: from ns.stardust.com (ziggy.stardust.com) [205.184.205.34] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10Zh4S-0000vQ-00; Tue, 20 Apr 1999 13:24:40 -0700 Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA26818 for ; Tue, 20 Apr 1999 13:11:41 -0700 Message-Id: <3.0.5.32.19990420131214.01cf9d90@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 20 Apr 1999 13:12:14 -0700 To: rem-conf@es.net From: Marty Bickford Subject: Education/Research Passes to iBAND2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Everyone, Stardust Forums is giving away a number of education and research passes to iBAND2. This technical conference is focused on Quality of Service-based Traffic Management, Measuring & Monitoring Traffic, Interdomain & Peered QoS & IP Multicast, Billing for Premium Services, & more If you fit this category, simply drop me some email. Of course, if you do work for an ISP, enterprise or vendor....you're invited too. Below are some of the highlights of iBAND2. Sincerely, Marty Bickford Conference Director ----------------------------------------------------------------- iBAND2 - The Internet Bandwidth Management Summit May 23-25, 1999 in San Francisco, California http://www.stardust.com/iband2/ ----------------------------------------------------------------- iBAND2 is a one-of-a-kind technical conference where attendees are immersed in the new Internet bandwidth technologies around the clock. It is your chance to explore the latest about smart bandwidth--it's not just about speed. Learn about the new bandwidth management technologies, deployment strategies, and business opportunities. Share the latest in-depth information not available anywhere else. If you are responsible for managing and growing network bandwidth, head for iBAND2. Explore ideas, insights and experiences with peers, partners and experts. Hear from the best and brightest minds in the Internet space. A must attend event for IP Network Professionals in enterprise, ISPs, and carrier organizations. Are you an enterprise executive looking to harness your network? Are you a network professional examining the future of your network? Are you a service provider looking to sell additional services and not just bandwidth? Discover how you can make and save money by offering new business services. Join us at iBAND2. Scroll down for details or click on a link. TECHNOLOGIES COVERED & WHITE PAPER http://www.stardust.com/iband2/tech_resources.htm QUALITY OF SERVICE (QoS) NETWORK SHOWCASE http://www.stardust.com/iband2/qos-showcase.htm FREE MP3 PLAYERS WITH PURCHASE OF CONFERENCE SESSIONS http://www.stardust.com/iband2/diamond.htm LEADING INTERNET TECHNOLOGISTS AT iBAND2 & THE AGENDA http://www.stardust.com/iband2/sessions.htm REGISTER TODAY & SAVE https://www.stardust.com/events/iband2/registration.htm TECHNOLOGIES COVERED & THE INTERNET BANDWIDTH MANAGEMENT WHITE PAPER -------------------------- iBAND2 is a one-of-a-kind technical and educational event, exploring the latest about smart bandwidth-- its not just about speed. Learn about the new bandwidth management technologies, deployment strategies, and business opportunities. Share the latest in-depth information not available anywhere else. Explore ideas with peers, partners and experts. Hot topics: * QoS, IP Multicast, DIFFSERV, RSVP, Policy, COPS, Directory Standards and Schema * Quality of Service-based Traffic Management, Measuring & Monitoring Traffic, Interdomain & Peered QoS & IP Multicast, Billing for Premium Services * Traffic prioritization, Voice over IP, SLA's, VPN's, Call Centers. Streaming Media, and more. Internet Bandwidth Management White Paper: Technologies, applications and business opportunities are the focus of an up-to-date 24 page white paper produced for iBAND. Download it today for free: http://www.stardust.com/iband2/whitepaper.hm QUALITY OF SERVICE (QoS) NETWORK SHOWCASE ----------------------------------------- 15 vendors are collaborating to build an end-to-end QoS Network. Attendees will experience the benefits and comparisons between applications with QoS enabled and disabled in a saturated network environment. Discuss the options and capabilities with the engineers who designed and built this extensive network. View policy management, directory services, traffic management and monitoring and more. http://www.stardust.com/iband2/qos-showcase.htm Participating companies include: 3Com, Cisco, Extreme, IPHighway, IPivot, Lucent, Microsoft, IBM, Intel, Novell, Orchestream, Qosnetics, Xedia, Netcom Systems, Nortel, and more. FREE MP3 PLAYERS WITH PURCHASE OF CONFERENCE SESSIONS ----------------------------------------- We know you can't attend more than one session at a time. In addition to receiving all materials electronically, Diamond Attendees receive a FREE Portable Conference Player (MP3 Player). We'll also include conference sessions from iBAND98 and MCAST99. http://www.stardust.com/iband2/diamond.htm THE LEADERS & THEIR SESSIONS ---------------------------------------------- Who will be there? Leading Internet technologists from the IETF, vendor and service providers. Our keynote: Scott Bradner of Harvard University. Mr. Bradner is the co director of the Transport Area in the IETF, is a member of the IESG, and an elected trustee of the Internet Society where he serves as the Vice President for Standards. He was also co director of the IETF IP next generation effort and is coeditor of "IPng: Internet Protocol Next Generation" from Addison-Wesley. Other distinguished presenters include: * Radia Perlman, Sun Microsystems * Shai Herzog, IPHighway * Bob Quinn, Stardust Forums * Winston Bumpus, Novell & DMTF * Benjamin Teitelbaum, Internet2 * Hal Sandick, Nortel * Yoram Bernet, Microsoft * Vasilis Theoharakis, 3Com * Rod Murchison, Newbridge * Ashley Stephenson, Xedia Corporation * Ed Perry, Hewlett-Packard * Charlie Muirhead, Orchestream * Mark Fishburn, NetCom Systems * Doug Sherman, 3Com * Adam Dunstan, Avici Systems * Tom Clarkson, IPivot * Jude O'Reilly, Aventail * Jeff Young, Cable & Wireless * Vijay Srinivasan, Torrent Networking Technologies * J. Christopher Landes, Lucent * and of course...many more. Click here for more details about the technical conference http://www.stardust.com/iband2/sessions.htm REGISTER ---------------------------------------------- ACT FAST. Sign up before April 23rd and save $200 http://www.stardust.com/iband2/ Nortel Networksis the Platinum Sponsor, IP Multicast Initiative & the Quality of Service Forum are Alliance Sponsors, and America's Network, Data Communications, InternetWeek and tele.com are Publication Sponsors of iBAND2. Contact Stardust Forums at (408)879-8080 with any questions regarding iBAND2. See you there. --- Marty Bickford - 408.879.8080 (8081-fax) Stardust Forums - http://www.stardust.com iBAND2(sm) - The Internet Bandwidth Management Summit From rem-conf Wed Apr 21 12:56:50 1999 From rem-conf-request@es.net Wed Apr 21 12:56:50 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10a2vR-0005g3-00; Wed, 21 Apr 1999 12:44:49 -0700 Received: from dad.isi.edu [128.9.160.202] by mail1.es.net with esmtp (Exim 1.81 #2) id 10a2vQ-0005ft-00; Wed, 21 Apr 1999 12:44:48 -0700 Received: from localhost (berson@localhost) by dad.isi.edu (8.8.8/8.8.8) with SMTP id MAA22489 for ; Wed, 21 Apr 1999 12:44:47 -0700 (PDT) (envelope-from berson@isi.edu) X-Authentication-Warning: dad.isi.edu: berson owned process doing -bs Date: Wed, 21 Apr 1999 12:44:47 -0700 (PDT) From: Steven Berson To: rem-conf@es.net Subject: Talk announcement (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We will be multicasting the following seminar on the sdr session entitled "Bob Metcalfe Seminar at USC/ISI". Sorry for the late notice. Steve USC/ISI Networking Seminar Series Topic: The Next Generation Internet Bob Metcalfe International Data Group April 21, 1999 1:30 PM PDT USC/Information Sciences Institute Dr. Metcalf will tell us his views on the Next Generation Internet. Bio: Technology pundit Bob Metcalfe is a successful engineer, entrepreneur, educator, and opinion leader in the high-tech community. After graduating from MIT and Harvard, Metcalfe joined the Xerox Palo Alto Research Center, where he invented Ethernet in 1973. Metcalfe is also noted for having founded 3Com Corporation, now a $5 billion global data networking company. In 1992 he joined the International Data Group where he serves as Vice President Technology and writer of an internationally syndicated weekly column in InfoWorld. In addition to Vortex, Metcalfe is the executive producer of Agenda, the annual gathering of the leaders of the computer industry. ---- On-line information about the ISI Network Seminars is available at http://www.isi.edu/divisions/div7/networking_seminar.html From rem-conf Wed Apr 21 16:46:10 1999 From rem-conf-request@es.net Wed Apr 21 16:46:09 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10a6cx-0004CU-00; Wed, 21 Apr 1999 16:41:59 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 10a6cv-0004C3-00; Wed, 21 Apr 1999 16:41:57 -0700 Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id QAA41840 for ; Wed, 21 Apr 1999 16:36:43 -0700 Received: from scv4.apple.com (scv4.apple.com) by mailgate2.apple.com (mailgate2.apple.com- SMTPRS 2.0.15) with ESMTP id for ; Wed, 21 Apr 1999 16:36:42 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv4.apple.com (8.9.3/8.9.3) with ESMTP id QAA51084 for ; Wed, 21 Apr 1999 16:35:09 -0700 MIME-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: Date: Wed, 21 Apr 1999 16:32:33 -0700 To: rem-conf@es.net From: Dave Singer Subject: Thanks to all the IETF... Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list we've just released our next version beta of quicktime, and it contains a lot of behavior for which we owe a large debt of gratitude to the IETF and the people who contribute to it. I hope you see the release as a ringing endorsement of open protocols and interoperable behavior, because that's the way we intend it; we have implemented RTP, RTSP, and SDP, and a number of codecs explicitly for interoperability. There's lots of details at , and I'd be happy to answer questions. But for those who contributed to, and continue to contribute to, RTP, RTSP, SDP, and the profiles (e.g. H263, H261, JPEG, and so on), especially the chairs and editors of the various groups and specifications, I say again, thanks. It's a treat to work in this industry with people like you. (Now you can flame me for the things we didn't do, or did wrong...) David Singer Apple Computer/QuickTime From rem-conf Wed Apr 21 19:01:10 1999 From rem-conf-request@es.net Wed Apr 21 19:01:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10a8iZ-0000JB-00; Wed, 21 Apr 1999 18:55:55 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 10a8iY-0000J1-00; Wed, 21 Apr 1999 18:55:54 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA16368; Wed, 21 Apr 1999 21:55:31 -0400 (EDT) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA16595; Wed, 21 Apr 1999 21:55:30 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <371E8192.B77F1D1E@cs.columbia.edu> Date: Wed, 21 Apr 1999 21:55:30 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net CC: Xiaotao Wu , "Kevin C. Almeroth" Subject: rtptools 1.12 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Xiaotao Wu, one of my students, has packaged a new version of the rtptools that now compiles more readily on Windows 95/NT. You can find the tools at http://www.cs.columbia.edu/~hgs/rtptools. Comments and suggestions are appreciated. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Thu Apr 22 04:53:41 1999 From rem-conf-request@es.net Thu Apr 22 04:53:39 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10aHwk-0007TB-00; Thu, 22 Apr 1999 04:47:10 -0700 Received: from razor.arnes.si [193.2.1.80] by mail1.es.net with esmtp (Exim 1.81 #2) id 10aHwf-0007Sp-00; Thu, 22 Apr 1999 04:47:08 -0700 Received: from wilfred (unknown [193.2.1.243]) by razor.arnes.si (Postfix) with SMTP id 6FDCBBEEC4 for ; Thu, 22 Apr 1999 13:45:47 +0200 (MET DST) Received: by localhost with Microsoft MAPI; Fri, 22 Jan 1999 13:56:28 +0100 Message-ID: <01BE460F.01E7BA10.chris@arnes.si> From: Chris van der Merwe Reply-To: "chris@arnes.si" To: "'rem-conf@es.net'" Subject: Bandwidth requirements for good quality Mbone videoconferencing... Date: Fri, 22 Jan 1999 13:56:27 +0100 Organization: Arnes X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 13 TEXT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi; We're an academic ISP setting up a Mbone videoconferencing demonstration between local cities to showcase the technology for local universities. I was wondering if anyone on the list had done a similar exercise and would have any pointers to what bandwidth would have to be guaranteed for good quality videoconferencing? We have decided to mainly use VIC, RAT (but also applications such as the WhiteBoard) for the demonstration. I'd be interested to hear other people's experiences and opinions. BTW We will probably be using Windows NT 4.0 as the Operating System Thanks Chris From rem-conf Thu Apr 22 06:00:30 1999 From rem-conf-request@es.net Thu Apr 22 06:00:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10aJ3N-00023I-00; Thu, 22 Apr 1999 05:58:05 -0700 Received: from nz40.rz.uni-karlsruhe.de (mailgate.rz.uni-karlsruhe.de) [129.13.197.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 10aJ3L-000230-00; Thu, 22 Apr 1999 05:58:03 -0700 Received: from nz50.rz.uni-karlsruhe.de (rz29@nz50.rz.uni-karlsruhe.de [129.13.98.9]) by mailgate.rz.uni-karlsruhe.de with smtp (Exim 2.04 #3) id 10aJ2D-000613-00; Thu, 22 Apr 1999 14:56:53 +0200 Date: Thu, 22 Apr 1999 14:56:54 +0200 (CES) From: Susanne Witschel To: Chris van der Merwe cc: "'rem-conf@es.net'" Subject: Re: Bandwidth requirements for good quality Mbone videoconferencing... In-Reply-To: <01BE460F.01E7BA10.chris@arnes.si> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 22 Jan 1999, Chris van der Merwe wrote: > We're an academic ISP setting up a Mbone videoconferencing demonstration > between local cities to showcase the technology for local universities. I > was wondering if anyone on the list had done a similar exercise and would > have any pointers to what bandwidth would have to be guaranteed for good > quality videoconferencing? We have decided to mainly use VIC, RAT (but also > applications such as the WhiteBoard) for the demonstration. The VIROR-Project (www.viror.de is the home page in German, with a pointer to an English version) in Germany uses ATM-PVCs with a supported Bandwith of 3Mbps in the backbone, nrt-VBR with an allowed peak rate of 100Mbps. At the Endpoints, edge devices are attached to the ATM-switches, which allow the Ethernet frames to be pumped into the ATM-backbone. We tried to copy the setup with an allowed peak rate of only 10Mbps, but had some problems, most probably because traffic shaping got lost somewhere between edge device and backbone switches, which do little buffering. We had it working all right with 15Mbps for short bursts, using vic, rat and dlb (whiteboard). As long as Your Edge devices and PCs don't provide more than 10Mbps, and You don't have any UBR Paths/Channels in between, 10Mbps might be worth a try. We didn't have any multicast routing mechanisms, this was layed out as one single ELAN (without LANE services). > I'd be interested to hear other people's experiences and opinions. BTW We > will probably be using Windows NT 4.0 as the Operating System Shouldn't be a problem as long as all Systems are NT - Multicast Routing is done in the Backbone, I suppose. I've heard something about the shrimp wb making wb on some WSs dump core. Anyone out there who remembers the thread? --suwi -- Susanne Witschel Videoconferencing - MBone - ATM-LHN Rechenzentrum Universitaet Karlsruhe e-mail: witschel@rz.uni-karlsruhe.de Zirkel 2 76128 Karlsruhe Tel.: ++49 (0)721/608-3784 GERMANY Fax : ++49 (0)721/32550 "Beware the ARPANET my son; The bits that byte, the heads that scratch; Beware the NCP, and shun the frumious system patch" (From RFC527, "ARPAWOCKY") From rem-conf Thu Apr 22 14:05:04 1999 From rem-conf-request@es.net Thu Apr 22 14:05:03 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10aQVM-00075x-00; Thu, 22 Apr 1999 13:55:28 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 10aQVL-00075X-00; Thu, 22 Apr 1999 13:55:27 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 0ADAA4CE09; Thu, 22 Apr 1999 16:55:26 -0400 (EDT) Received: from pcbasso.research.att.com (pcbasso [135.207.130.108]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id QAA01486; Thu, 22 Apr 1999 16:55:24 -0400 (EDT) Message-ID: <009501be8d02$6b83bfc0$6c82cf87@pcbasso.research.att.com> Reply-To: "Andrea Basso" From: "Andrea Basso" To: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Cc: , Subject: Updated info for the IETF/MPEG4 Meeting Date: Thu, 22 Apr 1999 16:55:13 -0400 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.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Info on the forthcoming MPEG/IETF meeting Sunday April 25 9am-5pm Columbia Univ. NY Detailed info on http://www.research.att.com/~mrc/mpeg4.htm The meeting will be held in the Interschool lab on the 7th floor of the Schapiro Research Bldg. at Columbia University's Morningside Heights campus, located in the Upper West Side of Manhattan. Directions The Schapiro Reserach Bdlg. (or Center for Engineering and Physical Science Research - CEPSR) is located at 530 West 120th Street, between Amsterdam Avenue and Broadway. There are entrances both from the campus side (at the 4th floor) as well as from the 120th Street side (2nd floor). If you come in from the 120th Street entrance, you will need to take a small elevator to go to the 4th floor. There you will find a set of elevators that can take you to all the other floors. Rooms are numbered by the floor they are located. Offices are located at the periphery of the building, and are numbered from 01 going clockwise and starting from the north. Laboratories are designated by the letter L, and their position (e.g., 7LE1 is a lab on the7th floor, in the east side of the building). Maps of Columbia's Morningside Heights Campus on the web site. IMPORTANT NOTE: there is *NO* access to the building during the weekend without a Columbia ID card. This means that all the attendees are supposed to be there at 9am sharp in front of the main door of the Schapiro Building. We are working on an arrangement to accommodate for the late comers. Please check this site for further developments. Anyone planning to participate in this meeting should be familiar with the mpeg4 over IP issues and related documents. If you are planning to join in discussion or consensus taking actions on any of the issues listed on the agenda, please read it first. If you have been listed as responsible for bringing up the issues relating to this document, please visit the mpeg over ip and the rem-conf mailing lists archives and conscientiously collect the major issues that have been raised and discussed thus far. The meeting co-chairs reserve the right to cut off anyone who is using WG time to pontificate rather than to advance the work items of the WG. A/V Equipment: Support for laptop (VGA) presentations as well as a viewgraph machine will be provided. LIST OF PARTICIPANTS: Laurent Hermann Steve Casner Guido Franceschini Jan van der Meer Christine Guillemot Stefan Wesner Anders Klemets Andrea Basso Carsten Herpel Zvi Lifshitz Dominique Curet Roberto Castagno Harri Honko Alexandros Eleftheriadis Hari Calva Norihito Takatori M. Ohno Robert Cohen Reha Civanlar Mukta L. Kar Atul Puri Hirokazu Tanaka Jun Sato Javier Zamora Mr. Kurokawa L. Gunaseelan Hidenobu Harasaki (afternoon) Kave Salamatian Stephan Wenger Laurence Rose Colin Perkins Peter Kaars Socrates Varakliotis AGENDA Allocation of contributions to appropriate sessions (9:00 - 9.15) Session I - Payload format issues (9.15 - 11.15) Highlight advantages of RTP over UDP transport using MPEG4 SL Highlight advantages of generic payload format (Guillemot et al.) Highlight advantages of MPEG-4 payload format (Civanlar et al.) Highlight advantages of RTP++/PES++ over current proposals (Franceschini) Discuss possibility to merge payload format proposals List major unresolved technical issues Session II - Multiplexing issues (11.30 - 1:00 and 2:00 - 3:00) Highlight advantages of multiplexing inside RTP Highlight advantages of using the same multiplex structure in MPEG-2 PES and RTP Estimate complexity and side effects of multiplexed packet conversion in gateways List major unresolved technical issues in order to facilitate the decision whether to use GeRM or FlexMux inside RTP Session III - IETF/MPEG timing/buffering model issues (3.15 - 4.30) Highlight differences between MPEG and IETF/RTP timing model and see how to convert between them. Highlight MPEG notion of buffer management. List major unresolved technical issues in order to assess feasibility of a common IETF/MPEG4 buffer management scenario Session IV - Closure (4.30 - 5:00) Summarize results of the discussions Allocation of editing tasks Allocation of sub-tasks to propose solutions for remaining technical issues (if needed) Session V - Late session (for those who can stay late) Start to solve remaining technical issues. SPECIAL THANKS: Prof. Alexandros Eleftheriadis, Columbia Univ. for the support and for offering the morning breakfast (thanks Alex!) Lourdes Dela Paz, financial account manager in EE Hari Calva, Columbia Univ. for the A/V equipment coordination/support See you all in NYC on Sunday -A Andrea Basso, AT&T Labs Research Room 3-219 100 Shultz Drive, Red Bank,NJ 07701 ph: (732) 345-3302 fax (732) 345-3033 basso@research.att.com From rem-conf Fri Apr 23 10:29:03 1999 From rem-conf-request@es.net Fri Apr 23 10:29:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ajei-0005vl-00; Fri, 23 Apr 1999 10:22:24 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ajeh-0005vb-00; Fri, 23 Apr 1999 10:22:23 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id KAA19966; Fri, 23 Apr 1999 10:22:21 -0700 (PDT) Message-Id: <3.0.3.32.19990423102220.00afa410@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 23 Apr 1999 10:22:20 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 4/28 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Why Understanding Anything About the Internet is Painfully Hard Wednesday April 28, 1999, 1:00-2:30 p.m. 405 Soda Hall Please note the time frame of the seminar series has changed!! Vern Paxson AT&T Center for Internet Research at ICSI The Internet poses immense challenges when attempting to measure, model, analyze, or extend it. The underlying problems are that the network is tremendously diverse, such that the notion of "typical" is rarely anything but misleading; it grows explosively, and has been doing so for years; and the traditional network modeling framework, based on Poisson assumptions of independence or at most weak traffic correlations, lies in ruins, destroyed by overwhelming measurement evidence. We sketch the fundamental causes of these difficulties and some of the strategies researchers have devised for coping with them. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Fri Apr 23 16:13:43 1999 From rem-conf-request@es.net Fri Apr 23 16:13:42 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ap11-0007dI-00; Fri, 23 Apr 1999 16:05:47 -0700 Received: from ganymede.or.intel.com [134.134.248.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 10ap0z-0007d8-00; Fri, 23 Apr 1999 16:05:45 -0700 Received: from orsmsx29.jf.intel.com (orsmsx29.jf.intel.com [192.168.65.29]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id XAA27479; Fri, 23 Apr 1999 23:05:37 GMT Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Apr 1999 16:05:37 -0700 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB201362D9C@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'internet-drafts@ietf.org'" , "'rem-conf@es.net'" Subject: draft-ietf-avt-rtp-mib-05.txt Date: Fri, 23 Apr 1999 16:05:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE8DDD.CC6FA009" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE8DDD.CC6FA009 Content-Type: text/plain; charset="ISO-8859-1" <> ------_=_NextPart_000_01BE8DDD.CC6FA009 Content-Type: text/plain; name="draft-ietf-avt-rtp-mib-05.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-avt-rtp-mib-05.txt" Audio Video Transport Group Mark Baugher Internet-Draft Intel Corp. Expires October 1999 Irena Suconick VideoServer Corp. Bill Strahm Intel Corp. April 12, 1999 Real-Time Transport Protocol Management Information Base =20 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``work inprogress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet- Drafts Shadow Directories on ftp.ietf.org, nic.nordu.net, venera.isi.edu, or munnari.oz.au. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time=20 Transport Protocol(RTP) systems [1]. Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page 1] =0C Internet Draft RTP MIB = April 1999 Table of Contents 1 The Network Management Framework ................................... = 3 2 Overview ........................................................... = 4 2.1 Components ....................................................... = 4 2.2 Applicability of the MIB to RTP System Implementations ........... = 4 2.3 The Structure of the RTP MIB ..................................... = 5 3 Definitions ........................................................ = 6 4 Security Issues .................................................... = 27 5 Acknowledgements ................................................... = 27 6 Intellectual Property .............................................. = 28 7 References ......................................................... = 28 8 Authors Addresses .................................................. = 30 9 Full Copyright Statement ........................................... = 31 Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page 2] =0C Internet Draft RTP MIB = April 1999 1. The Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [2]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [3], RFC 1212 [4] and RFC 1215 [5]. The second version, called SMIv2, is described in RFC 1902 [6], RFC 1903 [7] and RFC 1904 [8]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [9]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC 1906 [11]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [11], RFC 2272 [12] and RFC 2274 [13]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [9]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [14]. o A set of fundamental applications described in RFC 2273 [15] and the view-based access control mechanism described in RFC 2275 [16]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the=20 MIB. Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page 3] =0C Internet Draft RTP MIB = April 1999 2. Overview An "RTP System" may be a host end-system that runs an application program that sends or receives RTP data packets, or it may be an intermediate-system that forwards RTP packets. RTP Control=20 Protocol (RTCP) packets are sent by senders and receivers to=20 convey information about RTP packet transmission and reception [1]. RTP monitors may collect RTCP information on senders and receivers to and from an RTP host or intermediate-system. 2.1 Components The RTP MIB is structured around "session," "Receiver" and "Sender"=20 conceptual abstractions. 2.1.1 An "RTP session" is the "...association of participants communicating with RTP. For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). The destination transport addresses may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast addresses plus a common port pair," as defined in section 3 of [1]. 2.1.2 A "Sender" is identified within an RTP session by a 32-bit = numeric "Synchronization Source," or "SSRC", value and is "...the source of a=20 stream of RTP packets" as defined in section 3 of [1]. The sender is=20 also a source of RTCP Sender Report packets as specified in section 6 = of [1]. 2.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or multicast Receiver as described in 2.1.1, above. An RTP Receiver has=20 an SSRC value that is unique to the session. An RTP Receiver is a=20 source of RTCP Receiver Reports as specified in section 6 of [1]. 2.2 Applicability of the MIB to RTP System Implementations=20 The RTP MIB may be used in two types of RTP implementations, RTP Host Systems (end systems) and RTP Monitors, see section 3 of [1]. =20 Use of the RTP MIB for RTP Translators and Mixers, as defined in=20 section 7 of [1], is for further study. Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page 4] =0C Internet Draft RTP MIB = April 1999 2.2.1 RTP host Systems are end-systems that may use the RTP MIB=20 to collect RTP session and stream data that the host is sending or receiving; these data may be used by a network manager to detect and diagnose faults that occur over the life time of an RTP session as=20 in a "help-desk" scenario. 2.2.2 RTP Monitors of multicast RTP sessions may be third-party, or may be located in an RTP intermediate-system or in the RTP host. RTP=20 Monitors may use the RTP MIB to collect RTP session and stream=20 statistical data; these data may be used by a network manager for capacity planning and other network-management purposes. An RTP=20 Monitor may use the RTP MIB to collect data to permit a network=20 manager to detect and diagnose faults in RTP sessions, or to permit=20 a network manger to configure its operation. =20 2.2.3 Many host systems will want to keep track of streams beyond what they are sending and receiving. In a mixed mode system a host would = use=20 RTP data from the host to maintain data about streams it is sending and = receiving, and RTCP data to collect data about other hosts in the = session. For example an RTP host that is sending a stream would use data from its RTP stack to maintain the rtpSenderTable, however it may want to=20 maintain a rtpReceiverTable for endpoints that are receiving its = stream. To do this the host will collect RTCP data from the receivers of its stream to build the rtpReceiverTable. 2.3 The Structure of the RTP MIB There are three tables in the RTP MIB. The rtpSessionTable contains objects that describe active sessions at the host, intermediate system, or monitor. The rtpSenderTable contains information about senders to the RTP session. The rtpRcvrTable contains information about receivers of RTP session data.=20 For any particular RTP session, the rtpSessionMonitor object indicates=20 whether information about remote senders or receivers to the RTP=20 session are to be monitored. RTP sessions are monitored by the=20 RTP agent that updates rtpSenderTable and rtpRcvrTable objects with=20 information from RTCP reports from remote senders or remote receivers=20 respectively. =20 rtpSessionNewIndex is a global object that permits a network-management application to obtain a unique index for conceptual row creation in the rtpSessionTable. In this way the SNMP Set operation may be used to configure a monitor. Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page 5] =0C Internet Draft RTP MIB = April 1999 3. Definitions RTP-MIB DEFINITIONS ::=3D BEGIN IMPORTS Counter32, Counter64, Gauge32, mib-2, Integer32, MODULE-IDENTITY, OBJECT-IDENTITY,=20 OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI DisplayString, RowStatus, TAddress,=20 TDomain, TestAndIncr, TEXTUAL-CONVENTION,=20 TimeStamp, TruthValue FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF InterfaceIndex FROM IF-MIB; rtpMIB MODULE-IDENTITY =20 LAST-UPDATED "990222000Z" ORGANIZATION "IETF AVT Working Group" =20 CONTACT-INFO "Mark Baugher =20 Postal: Intel Corporation 2111 NE 25th Avenue =20 Hillsboro, OR 97124 United States =20 Tel: +1 503 264 3849 Email: mbaugher@intel.com =20 =09 Bill Strahm Postal: Intel Corporation =20 2111 NE 25th Avenue Hillsboro, OR 97124 =20 United States Tel: +1 503 264 4632 =20 Email: bill.strahm@intel.com =20 Irina Suconick =20 Postal: Videoserver Corporation 63 Third Street =20 Burlington, MA 01803 United States =20 Tel: +1 781-505-2155 Email: isuconick@videoserver.com" Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page 6] =0C Internet Draft RTP MIB = April 1999 DESCRIPTION =20 "The managed objects of RTP systems. The MIB is=20 structured around three types of information. 1. General information about RTP sessions such as the session address. 2. Information about RTP streams being sent to an RTP session by a particular sender. =20 3. Information about RTP streams received on an RTP session by a particular receiver from a=20 particular sender. There are two types of RTP Systems, RTP hosts and RTP monitors. As described below, certain objects are unique to a particular type of RTP System. An RTP host may also function as an RTP monitor. Refer to RFC 1889, 'RTP: A Transport Protocol for=20 Real-Time Applications,' section 3.0, for definitions." ::=3D=3D { mib-2 xx } -- to be assigned by IANA when going to Proposed -- -- OBJECTS -- rtpMIBObjects OBJECT IDENTIFIER ::=3D { rtpMIB 1 } rtpAdmin OBJECT IDENTIFIER ::=3D { rtpMIB 2 } rtpConformance OBJECT IDENTIFIER ::=3D { rtpMIB 3 } rtpDomains OBJECT IDENTIFIER ::=3D { rtpMIB 4 } rtpUDPDomain OBJECT-IDENTITY STATUS current =20 DESCRIPTION "RTP over UDP transport domain over IPv4. This definition=20 uses the transport address type, snmpUDPAddress, which is=20 defined in SNMPv2-TM, 'Transport Mappings for Version 2 of=20 the Simple Network Management Protocol (SNMPv2)'." REFERENCE "RFC 1906, sec. 2 " ::=3D { rtpDomains 1 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page 7] =0C Internet Draft RTP MIB = April 1999 -- =20 -- SESSION TABLE -- rtpSessionNewIndex OBJECT-TYPE SYNTAX TestAndIncr =20 MAX-ACCESS read-write STATUS current =20 DESCRIPTION "This object is used to assign values to=20 rtpSessionIndex as described in 'Textual Conventions for SNMPv2'. For an RTP monitor system, the network manager would read=20 the object, and then write the value back in the Set that creates a new instance of rtpSessionEntry. If the Set fails with the code 'inconsistentValue,' then the process must be=20 repeated; If the Set succeeds, then the object is incremented, and the new instance is created according to the manager's directions. However, if the RTP agent is not acting as a monitor,=20 only the RTP agent may create conceptual rows in the RTP session table. The RTP agent is a monitor for a=20 paricular session only if rtpSessionMonitor is set to=20 'true(1)'." =20 ::=3D { rtpMIBObjects 1 } rtpSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSessionEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "There's one entry in rtpSessionTable for each RTP session on which packets are being sent, received, and/or=20 monitored." =20 ::=3D { rtpMIBObjects 2 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page 8] =0C Internet Draft RTP MIB = April 1999 rtpSessionEntry OBJECT-TYPE =20 SYNTAX RtpSessionEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION =20 "Data in rtpSessionTable uniquely identify an RTP=20 session. A host RTP agent will create a read-only row for each session to which packets are being sent or received.=20 An RTP session can be monitored to create management=20 information on all RTP streams being sent or received when the rtpSessionMonitor has the TruthValue of 'true(1)'. An RTP monitor may permit row creation with the side effect of causing the RTP System to join the multicast session = for=20 the purposes of gathering management information (thus=20 additional conceptual rows are created in the rtpRcvrTable and rtpSenderTable). Thus, rtpSessionTable rows can be created=20 for RTP session monitoring purposes. Rows created by a=20 management application may be deleted via SNMP operations. Rows created by a management application (rtpSessionMonitor=20 is 'true(1)') are deleted by the management application. When rtpSessionMonitor is 'false(2), rows are created by the=20 RTP Agent at the start of a session when one or more or more=20 senders or receivers are observed. Rows created by an RTP=20 agent are deleted when the session is over and there are no=20 rtpRcvrEntry and no rtpSenderEntry for this session." INDEX { rtpSessionIndex } =20 ::=3D { rtpSessionTable 1 } RtpSessionEntry ::=3D SEQUENCE { =20 rtpSessionIndex Integer32, rtpSessionDomain TDomain, =20 rtpSessionRemAddr TAddress, rtpSessionLocAddr TAddress, rtpSessionIfIndex InterfaceIndex, rtpSessionSenderJoins Counter32, rtpSessionReceiverJoins Counter32, rtpSessionByes Counter32, rtpSessionStartTime TimeStamp, rtpSessionMonitor TruthValue, rtpSessionRowStatus RowStatus =20 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page 9] =0C Internet Draft RTP MIB = April 1999 rtpSessionIndex OBJECT-TYPE =20 SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "The index of the conceptual row which is for SNMP purposes only and has no relation to any protocol value. There is no requirement that these rows are created or maintained sequentially." ::=3D { rtpSessionEntry 1}=20 rtpSessionDomain OBJECT-TYPE SYNTAX TDomain =20 MAX-ACCESS read-create STATUS current =20 DESCRIPTION "The transport-layer protocol used for sending or receiving the stream of RTP data packets on this session. Cannot be changed if rtpSessionRowStatus is 'active'." DEFVAL { rtpUDPDomain } =20 ::=3D { rtpSessionEntry 2 } rtpSessionRemAddr OBJECT-TYPE =20 SYNTAX TAddress MAX-ACCESS read-create =20 STATUS current DESCRIPTION "The remote destination transport address on which the=20 RTP data packet stream is sent and/or received. 'The=20 destination address pair may be common for all participants,=20 as in the case of IP multicast, or may be different for each,=20 as in the case of individual unicast network address pairs.' =20 See RFC 1889, 'RTP: A Transport Protocol for Real-Time=20 Applications,' sec. 3. The transport service is identified=20 by rtpSessionDomain. For rtpUDPDomain, this is an IP address=20 and even-numbered UDP Port with the RTCP being sent on the=20 next higher odd-numbered port, see RFC 1889, sec. 5. Cannot=20 be changed if rtpSessionRowStatus is 'active'." =20 ::=3D { rtpSessionEntry 3 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 10] =0C Internet Draft RTP MIB = April 1999 rtpSessionLocAddr OBJECT-TYPE =20 SYNTAX TAddress MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The local destination transport address on which the stream of data packets is being sent and/or received. For unicast RTP sessions, this is the local address of the RTP session. For multicast RTP sessions, this object should have the same value as rtpSessionRemoteAddr. See RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 3. The transport service is identified by rtpSessionDomain. For rtpUDPDomain, this is an IP address and even-numbered=20 UDP Port with the RTCP being sent on the next higher=20 odd-numbered port, see RFC 1889, sec. 5." ::=3D { rtpSessionEntry 4 } rtpSessionIfIndex OBJECT-TYPE SYNTAX InterfaceIndex =20 MAX-ACCESS read-create STATUS current =20 DESCRIPTION "The ifIndex value is set to the corresponding value=20 from the Internet Standard MIB. This is the interface that the RTP stream is being sent to or received from,=20 or in the case of an RTP Monitor the interface that RTCP packets will be received on. Cannot be changed if=20 rtpSessionRowStatus is 'active'." =20 DEFVAL { 1 } =20 ::=3D { rtpSessionEntry 5 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 11] =0C Internet Draft RTP MIB = April 1999 rtpSessionSenderJoins OBJECT-TYPE SYNTAX Counter32 =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "The number of senders that have been observed to have joined the session since this conceptual row was created (rtpSessionStartTime). A sender 'joins' an RTP session by sending to it. Senders that leave and then=20 re-join following an RTCP BYE (See RFC 1889, 'RTP: A=20 Transport Protocol for Real-Time Applications,' sec. 6.6) or session timeout may be counted twice. Every time a new RTP sender is detected either using RTP or RTCP, this counter is incremented." =20 ::=3D { rtpSessionEntry 6 } rtpSessionReceiverJoins OBJECT-TYPE =20 SYNTAX Counter32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The number of receivers that have been been observed to have joined this session since this conceptual row was created (rtpSessionStartTime). Receivers that leave and=20 then re-join following an RTCP BYE (See RFC 1889, 'RTP: A=20 Transport Protocol for Real-Time Applications,' sec. 6.6) or session timeout may be counted twice. Every time an RTP receiver is detected using RTCP, this counter is=20 incremented." =20 ::=3D { rtpSessionEntry 7 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 12] =0C Internet Draft RTP MIB = April 1999 rtpSessionByes OBJECT-TYPE =20 SYNTAX Counter32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "A count of RTCP BYE (See RFC 1889, 'RTP: A Transport=20 Protocol for Real-Time Applications,' sec. 6.6) messages=20 received by this entity." =20 ::=3D { rtpSessionEntry 8 } rtpSessionStartTime OBJECT-TYPE =20 SYNTAX TimeStamp MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The value of SysUpTime at the time that this row was=20 created." =20 ::=3D { rtpSessionEntry 9 } rtpSessionMonitor OBJECT-TYPE =20 SYNTAX TruthValue MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Boolean, Set to 'true(1)' if senders or receivers in=20 addition to the local RTP System are to be monitored. =20 RTP Monitors MUST initialize to 'true(1)' and RTP=20 Hosts MUST initialize this 'false(2)'." ::=3D { rtpSessionEntry 10 } rtpSessionRowStatus OBJECT-TYPE SYNTAX RowStatus =20 MAX-ACCESS read-create STATUS current =20 DESCRIPTION "Value of 'active' when RTP or RTCP messages are being=20 sent or received by an RTP System. A newly-created conceptual row must have the rtpSessionRemAddr and rtpSessionLocAddr initialized before becoming 'active'. A conceptual row that is in the 'notReady' or 'notInService' state MAY be removed after 5 minutes." ::=3D { rtpSessionEntry 11 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 13] =0C Internet Draft RTP MIB = April 1999 -- -- SENDERS TABLE -- rtpSenderTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSenderEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "Table of information about a sender or senders to an RTP=20 Session. RTP sending hosts MUST have an entry in this table=20 for each stream being sent. RTP reveiving hosts MAY have an=20 entry in this table for each sending stream being received=20 by this host. RTP monitors create an entry for each observed=20 sender to a multicast RTP Session as a side-effect when a=20 conceptual row in the rtpSessionTable is made 'active' by a=20 manager." =20 ::=3D { rtpMIBObjects 3 } rtpSenderEntry OBJECT-TYPE =20 SYNTAX RtpSenderEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "Each entry contains information from a single RTP Sender=20 Synchronization Source (SSRC, see RFC 1889 'RTP: A Transport=20 Protocol for Real-Time Applications' sec.6). The session is identified to the the SNMP entity by rtpSessionIndex. Rows are removed by the RTP agent when a BYE is received from the sender or when the sender times out (see RFC 1889, Sec. 6.2.1)." INDEX { rtpSessionIndex, rtpSenderSSRC } =20 ::=3D { rtpSenderTable 1 } RtpSenderEntry ::=3D SEQUENCE { =20 rtpSenderSSRC Unsigned32, rtpSenderCNAME DisplayString, rtpSenderAddr TAddress, rtpSenderPackets Counter64, rtpSenderOctets Counter64, rtpSenderTool DisplayString, rtpSRs Counter32, rtpSenderSRTime TimeStamp, =20 rtpSenderPT INTEGER, rtpSenderStartTime TimeStamp =20 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 14] =0C Internet Draft RTP MIB = April 1999 rtpSenderSSRC OBJECT-TYPE =20 SYNTAX Unsigned32 MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "The RTP SSRC, or synchronization source identifier of the sender. The RTP session address plus an SSRC uniquely=20 identify a sender to an RTP stream (see RFC 1889, 'RTP: A=20 Transport Protocol for Real-Time Applications' sec.3)." =20 ::=3D { rtpSenderEntry 1 } rtpSenderCNAME OBJECT-TYPE =20 SYNTAX DisplayString (SIZE(0..255)) MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The RTP canonical name of the sender." =20 ::=3D { rtpSenderEntry 2 } rtpSenderAddr OBJECT-TYPE =20 SYNTAX TAddress MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The unicast transport source address of the sender." ::=3D { rtpSenderEntry 3 } rtpSenderPackets OBJECT-TYPE SYNTAX Counter64 =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "Count of RTP packets sent by this sender, or observed by an RTP monitor, since rtpSenderStartTime." ::=3D { rtpSenderEntry 4 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 15] =0C Internet Draft RTP MIB = April 1999 rtpSenderOctets OBJECT-TYPE =20 SYNTAX Counter64 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Count of RTP octets sent by this sender, or observed by an RTP monitor, since rtpSenderStartTime." ::=3D { rtpSenderEntry 5 } rtpSenderTool OBJECT-TYPE SYNTAX DisplayString (SIZE(0..127)) MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Name of the application program source of the stream." DEFVAL { ''H } -- Null if not available =20 ::=3D { rtpSenderEntry 6 } rtpSRs OBJECT-TYPE =20 SYNTAX Counter32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "A count of the number of RTCP Sender Reports that have=20 been sent from this sender, or observed if the RTP entity is a monitor, since rtpSenderStartTime." ::=3D { rtpSenderEntry 7 } rtpSenderSRTime OBJECT-TYPE SYNTAX TimeStamp =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "rtpSenderSRTime is the value of SysUpTime at the time that the last SR was received from this sender, in the case of a monitor or receiving host. Or sent by this sender, in the=20 case of a sending host." =20 ::=3D { rtpSenderEntry 8 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 16] =0C Internet Draft RTP MIB = April 1999 rtpSenderPT OBJECT-TYPE =20 SYNTAX INTEGER (0..127) MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Static or dynamic payload type from the RTP header (see=20 RFC 1889, 'RTP: A Transport Protocol for Real-Time=20 Applications' sec. 5)." =20 ::=3D { rtpSenderEntry 9 } rtpSenderStartTime OBJECT-TYPE =20 SYNTAX TimeStamp MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The value of SysUpTime at the time that this row was=20 created." =20 ::=3D { rtpSenderEntry 10 } -- -- RECEIVERS TABLE -- rtpRcvrTable OBJECT-TYPE =20 SYNTAX SEQUENCE OF RtpRcvrEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION "Table of information about a receiver or receivers of RTP=20 session data. RTP hosts that receive RTP session packets=20 MUST create an entry in this table for that receiver/sender=20 pair. RTP hosts that send RTP session packets MAY create an entry in this table for each receiver to their stream using RTCP feedback from the RTP group. RTP monitors=20 create an entry for each observed RTP session receiver as a side effect when a conceptual row in the rtpSessionTable is made 'active' by a manager." ::=3D { rtpMIBObjects 4 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 17] =0C Internet Draft RTP MIB = April 1999 rtpRcvrEntry OBJECT-TYPE =20 SYNTAX RtpRcvrEntry MAX-ACCESS not-accessible =20 STATUS current DESCRIPTION =20 "Each entry contains information from a single RTP=20 Synchronization Source that is receiving packets from the=20 sender identified by rtpRcvrSRCSSRC (SSRC, see RFC 1889,=20 'RTP: A Transport Protocol for Real-Time Applications'=20 sec.6). The session is identified to the the SNMP entity by=20 rtpSessionIndex. Rows are removed by the RTP agent when=20 a BYE is received from the sender or when the sender times=20 out (see RFC 1889, Sec. 6.2.1)." INDEX { rtpSessionIndex, rtpRcvrSRCSSRC, rtpRcvrSSRC } ::=3D { rtpRcvrTable 1 } RtpRcvrEntry ::=3D SEQUENCE { rtpRcvrSRCSSRC Unsigned32, =20 rtpRcvrSSRC Unsigned32, rtpRcvrCNAME DisplayString, rtpRcvrAddr TAddress, =20 rtpRcvrRTT Gauge32, rtpRcvrLostPackets Counter64, =20 rtpRcvrJitter Gauge32, rtpRcvrTool DisplayString, rtpRRs Counter32, rtpRcvrRRTime TimeStamp, =20 rtpRcvrPT INTEGER,=20 rtpRcvrPackets Counter64, =20 rtpRcvrOctets Counter64, rtpRcvrStartTime TimeStamp =20 } rtpRcvrSRCSSRC OBJECT-TYPE SYNTAX Unsigned32 =20 MAX-ACCESS not-accessible STATUS current =20 DESCRIPTION "The RTP SSRC, or synchronization source identifier of the sender. The RTP session address plus an SSRC uniquely=20 identify a sender or receiver of an RTP stream (see RFC=20 1889, 'RTP: A Transport Protocol for Real-Time=20 Applications' sec.3)." =20 ::=3D { rtpRcvrEntry 1 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 18] =0C Internet Draft RTP MIB = April 1999 rtpRcvrSSRC OBJECT-TYPE =20 SYNTAX Unsigned32 MAX-ACCESS not-accessible =20 STATUS current =20 DESCRIPTION "The RTP SSRC, or synchronization source identifier of the receiver. The RTP session address plus an SSRC uniquely=20 identify a receiver of an RTP stream (see RFC 1889, 'RTP: =20 A Transport Protocol for Real-Time Applications' sec.3)." =20 ::=3D { rtpRcvrEntry 2 } rtpRcvrCNAME OBJECT-TYPE =20 SYNTAX DisplayString (SIZE(0..255)) MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The RTP canonical name of the receiver." =20 ::=3D { rtpRcvrEntry 3 } rtpRcvrAddr OBJECT-TYPE =20 SYNTAX TAddress =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "The unicast transport address of the receiver." ::=3D { rtpRcvrEntry 4 } rtpRcvrRTT OBJECT-TYPE =20 SYNTAX Gauge32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The round trip time measurement taken by the source of the=20 RTP stream based on the algorithm described on sec. 6 of=20 RFC 1889, 'RTP: A Transport Protocol for Real-Time=20 Applications.' This algorithm can produce meaningful=20 results when the RTP agent has the same clock as the stream=20 sender (when the RTP monitor is also the sending host for the particular reciever). Otherwise, the entity should return=20 'noSuchInstance' in response to queries against rtpRcvrRTT." ::=3D { rtpRcvrEntry 5 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 19] =0C Internet Draft RTP MIB = April 1999 rtpRcvrLostPackets OBJECT-TYPE =20 SYNTAX Counter64=20 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "A count of RTP packets lost as observed by this receiver since rtpRcvrStartTime." =20 ::=3D { rtpRcvrEntry 6 } rtpRcvrJitter OBJECT-TYPE =20 SYNTAX Gauge32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "An estimate of delay variation as observed by this=20 receiver. (see RFC 1889, 'RTP: A Transport Protocol=20 for Real-Time Applications' sec.6.3.1 and A.8)." ::=3D { rtpRcvrEntry 7 } rtpRcvrTool OBJECT-TYPE =20 SYNTAX DisplayString (SIZE(0..127)) MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Name of the application program source of the stream." DEFVAL { ''H } -- Null if not available =20 ::=3D { rtpRcvrEntry 8 } rtpRRs OBJECT-TYPE =20 SYNTAX Counter32 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "A count of the number of RTCP Receiver Reports that have=20 been sent from this receiver, or observed if the RTP entity is a monitor, since rtpRcvrStartTime." ::=3D { rtpRcvrEntry 9 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 20] =0C Internet Draft RTP MIB = April 1999 rtpRcvrRRTime OBJECT-TYPE =20 SYNTAX TimeStamp MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "rtpRcvrRRTime is the value of SysUpTime at the time that the=20 last RTCP Receiver Report was received from this receiver, in=20 the case of a monitor or RR receiver (the RTP Sender). It is the value of SysUpTime at the time that the last RR was sent by=20 this receiver in the case of an RTP receiver sending the RR." ::=3D { rtpRcvrEntry 10 } rtpRcvrPT OBJECT-TYPE SYNTAX INTEGER (0..127) =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "Static or dynamic payload type from the RTP header (see=20 RFC 1889, 'RTP: A Transport Protocol for Real-Time=20 Applications' sec. 5)." =20 ::=3D { rtpRcvrEntry 11 } rtpRcvrPackets OBJECT-TYPE =20 SYNTAX Counter64 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "Count of RTP packets received by this RTP host receiver=20 since rtpRcvrStartTime. RTP monitors may not have this information and should return 'noSuchInstance.'" ::=3D { rtpRcvrEntry 12 } rtpRcvrOctets OBJECT-TYPE SYNTAX Counter64 =20 MAX-ACCESS read-only STATUS current =20 DESCRIPTION "Count of RTP octets received by this receiving RTP host=20 since rtpRcvrStartTime. RTP monitors may not have this this information and should return 'noSuchInstance.'" ::=3D { rtpRcvrEntry 13 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 21] =0C Internet Draft RTP MIB = April 1999 rtpRcvrStartTime OBJECT-TYPE =20 SYNTAX TimeStamp MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION "The value of SysUpTime at the time that this row was=20 created." =20 ::=3D { rtpRcvrEntry 14 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 22] =0C Internet Draft RTP MIB = April 1999 -- -- MODULE GROUPS -- rtpGroups OBJECT IDENTIFIER ::=3D { rtpConformance 1 } rtpSystemGroup OBJECT-GROUP =20 OBJECTS { rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex, rtpSessionSenderJoins, rtpSessionReceiverJoins, rtpSessionStartTime, rtpSessionRowStatus, rtpSessionByes, =20 rtpSessionMonitor, rtpSenderCNAME, =20 rtpSenderAddr, rtpSenderPackets, =20 rtpSenderOctets, rtpSenderTool, =20 rtpSRs, rtpSenderSRTime, rtpSenderStartTime, =20 rtpRcvrCNAME, rtpRcvrAddr, =20 rtpRcvrLostPackets, rtpRcvrJitter, =20 rtpRcvrTool, rtpRRs, =20 rtpRcvrRRTime, rtpRcvrStartTime =20 } STATUS current =20 DESCRIPTION =20 "Objects used by any RTP systems." =20 ::=3D { rtpGroups 1 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 23] =0C Internet Draft RTP MIB = April 1999 rtpHostGroup OBJECT-GROUP =20 OBJECTS { rtpSessionLocAddr, =20 rtpSenderPT, rtpRcvrPT, =20 rtpRcvrRTT, rtpRcvrOctets, =20 rtpRcvrPackets } =20 STATUS current =20 DESCRIPTION =20 "Objects used by RTP host systems." =20 ::=3D { rtpGroups 2 } rtpMonitorGroup OBJECT-GROUP =20 OBJECTS { rtpSessionNewIndex =20 } STATUS current =20 DESCRIPTION "Objects used by RTP monitor systems." =20 ::=3D { rtpGroups 3 } -- -- Compliance -- rtpCompliances OBJECT IDENTIFIER ::=3D { rtpConformance 2 } rtpHostCompliance MODULE-COMPLIANCE =20 STATUS current DESCRIPTION =20 "Host implementations must comply." MODULE RTP-MIB =20 MANDATORY-GROUPS { rtpSystemGroup } GROUP rtpHostGroup =20 DESCRIPTION "The objects in the rtpHostGroup MUST be implemented in RTP host systems that are the source or the destination of RTP data packets." ::=3D { rtpCompliances 1 } Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 24] =0C Internet Draft RTP MIB = April 1999 rtpMonitorCompliance MODULE-COMPLIANCE =20 STATUS current DESCRIPTION =20 "Monitor implementations must comply." MODULE RTP-MIB =20 MANDATORY-GROUPS {=20 rtpSystemGroup, rtpHostGroup =20 } GROUP rtpMonitorGroup =20 DESCRIPTION "The objects in the rtpMonitorGroup MUST be implemented in RTP monitors." =20 OBJECT rtpSessionNewIndex MIN-ACCESS not-accessible =20 DESCRIPTION "RTP host system implementations support of row creation and deletion is OPTIONAL so implementation of this object is OPTIONAL." OBJECT rtpSessionDomain =20 MIN-ACCESS read-only DESCRIPTION "RTP host system implementation support of row creation and deletion is OPTIONAL. When it is not supported so write access is=20 OPTIONAL." =20 OBJECT rtpSessionRemAddr MIN-ACCESS read-only =20 DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionIfIndex =20 MIN-ACCESS read-only DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 25] =0C Internet Draft RTP MIB = April 1999 OBJECT rtpSessionRowStatus =20 MIN-ACCESS not-accessible DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionLocAddr =20 MIN-ACCESS not-accessible DESCRIPTION "RTP monitor sourcing of RTP or RTCP data packets=20 is OPTIONAL and implementation of this object is=20 OPTIONAL." =20 OBJECT rtpRcvrPT MIN-ACCESS not-accessible =20 DESCRIPTION "RTP monitor systems NEED NOT support retrieval of the RTP Payload Type from the RTP=20 header (and may receive RTCP messages only). When queried for the payload type information, the=20 RTP agent may return 'noSuchObject'." OBJECT rtpSenderPT =20 MIN-ACCESS not-accessible DESCRIPTION "RTP monitor systems may recieve only the RTCP messages and not the RTP messages that contain the payload type information in the header. Thus implementation of this object is OPTIONAL." =20 OBJECT rtpRcvrOctets MIN-ACCESS not-accessible =20 DESCRIPTION "RTP monitor systems may recieve only the RTCP messages and not the RTP messages that contain the octet count of the RTP message. Thus implementation of this object is OPTIONAL." =20 OBJECT rtpRcvrPackets MIN-ACCESS not-accessible =20 DESCRIPTION "RTP monitor systems may recieve only the RTCP messages and not the RTP messages that contain the octet count of the RTP message. Thus implementation of this object is OPTIONAL." =20 ::=3D { rtpCompliances 2 } END Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 26] =0C Internet Draft RTP MIB = April 1999 4. Security Issues In most cases, MIBs are not themselves security risks; if SNMP security = is=20 operating as intended, the use of a MIB to view information about a=20 system, or to change some parameter at the system, is a tool, not a = threat. None of the read-only objects in this MIB reports a password, though some SDES items such as the CNAME, the canonical name, may be deemed sensitive depending on the security policies of a particular=20 enterprise. If access to these objects is not limited by an=20 appropriate access control policy, these objects can provide an=20 attacker with information about a system's configuration and the=20 services that that system is providing. Some enterprises view their=20 network and system configurations, as well as information about=20 usage and performance, as corporate assets; such enterprises may=20 wish to restrict SNMP access to most of the objects in the MIB. This MIB supports read-write operations against rtpSessionNewIndex = which has the side effect of creating an entry in the rtpSessionTable when it is written to. Five objects in rtpSessionEntry have read-create = access: rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex,=20 rtpSessionRowStatus rtpSessionIfAddr identify an RTP session to be=20 monitored on a particular interface. The values of these objects are=20 not to be changed once created, and initialization of these objects=20 affects only the monitoring of an RTP session and not the operation of=20 an RTP session on any host end-system. Since write operations to=20 rtpSessionNewIndex and the five objects in rtpSessionEntry affect the=20 operation of the monitor, write access to these objects should be=20 subject to the appropriate access control policy. Confidentiality of RTP and RTCP data packets is defined in section 9 of = the RTP specification [1]. Encryption may be performed on RTP packets, RTCP packets, or both. Encryption of RTCP packets may pose a problem for third-party monitors though "For RTCP, it is allowed to split a compound RTCP packet into two lower-layer packets, one to be encrypted and one to be sent in the clear. For example, SDES information might be encrypted while reception reports were sent in the clear to=20 accommodate third-party monitors [1]." =20 5. Acknowledgements The authors wish to thank Bert Wijnen and the participants from the=20 ITU SG-16 management effort for their helpful comments. Alan Batie and Bill Lewis from Intel also contributed greatly to the RTP MIB through their review of various drafts of the MIB and their work on the implementation of an SNMP RTP Monitor. Stan Naudus from 3Com=20 and John Du from Intel contributed to the original RTP MIB design and=20 co-authored the original RTP MIB draft documents; much of their work=20 remains in the current RTP MIB. =20 Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 27] =0C Internet Draft RTP MIB = April 1999 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. References [1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for real-time applications," RFC 1889. [2] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [3] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [4] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [5] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 28] =0C Internet Draft RTP MIB = April 1999 [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management = Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, = "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [9] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple = Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [12] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron = Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [13] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) = for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [14] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 29] =0C Internet Draft RTP MIB = April 1999 [15] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC=20 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco=20 Systems, January 1998 [16] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 8. Authors Addresses Mark Baugher Email: mbaugher@intel.com Intel Corporation 2111 N.E.25th Avenue =20 Hillsboro, Oregon 97124 U.S.A. =20 Bill Strahm Email: Bill.Strahm@intel.com =20 Intel Corporation 2111 N.E.25th Avenue =20 Hillsboro, Oregon 97124 U.S.A. =20 Irena Suconick Email: isuconick@videoserver.com Videoserver Corporation 63 Third Street Burlington, Massachusetts 01803 U.S.A. Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 30] =0C Internet Draft RTP MIB February 26, = 1998 9. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. =20 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. =20 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. =20 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =20 Baugher, Strahm, Suconick Expires Oct 12, 1999 [Page = 31] =0C ------_=_NextPart_000_01BE8DDD.CC6FA009-- From rem-conf Sun Apr 25 13:43:00 1999 From rem-conf-request@es.net Sun Apr 25 13:42:59 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 10bVZ9-0000PT-00; Sun, 25 Apr 1999 13:31:51 -0700 Received: from 1cust190.tnt2.west-palm-beach.fl.da.uu.net ([208.253.43.190] helo=mail.somedomainsomewhere.com) by mail2.es.net with smtp (Exim 1.92 #1) id 10bVZ2-0000OE-00; Sun, 25 Apr 1999 13:31:45 -0700 From: Subject: HUMAN GROWTH HORMONES AD Date: Sun, 25 Apr 1999 15:14:01 Message-Id: Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Human Growth Hormone Available Now Without A Prescription Biggest Medical Breakthrough in Fat Loss & Anti-Aging in the 20th Century Order now and receive a "FREE GIFT" 1-800-955-5553 Now, for the first time ever, Human Growth Hormone is available without a prescription! Doctors have known for years that HGH : Decreases in;body fat, wrinkling, cholesterol, insomnia. Increases in;Physical strength, muscle mass, energy level, sexual function, mental alertness. Feelings of well being Stimulates youthful skin and hair appearance. Improves neurological function. Rejuvenates cell and organ tissue. HGH is now available to you in a SAFE, ALL NATURAL ORGANIC FORMULA, with no side effects when taken in a recommended dosage. HGH is a naturally occuring substance secreted by the pituitary gland, as our bodies age the pituitary's production of Human Growth Hormone decreases. The production of HGH helps slow down, and in some cases, even reverse the aging process. Over 1,000 doctors that atteneded the Anti-Aging conference in December agreed that HGH is one of the "most exciting advancements in reversing the disease of aging," since the introduction of DHEA. HGH has been used in Europe and the United States for approximately 15 years with amazing results. It has previously been available by injection only, and since injections by doctors cost between $5,000.00 and $20,000.00 a year, only the wealthy were able to afford these treatments. Now everyone can afford and receive the benefits of HGH. Now it is available for less than $100.00 per month in a handy application that you spray under your tongue, for instant absorption and FAST ACTING RESULTS!!! If you are interested in improving your quality of life, and your overall feeling of well being, then call 1-800-955-5553 to order your supply of HGH. Call within 24 hours of receiving this special offer and "get a FREE gift" from ADVANCED LABS. IF YOU CANNOT GET THROUGH TO OUR 800 NUMBER TRY THE FOLLOWING: FAX:530 2230699 to be removed email hormoneboy21@eastmail.com From rem-conf Mon Apr 26 01:43:12 1999 From rem-conf-request@es.net Mon Apr 26 01:43:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10bguk-0001A6-00; Mon, 26 Apr 1999 01:38:54 -0700 Received: from dsii.dsi.unifi.it [150.217.15.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 10bguh-00019w-00; Mon, 26 Apr 1999 01:38:51 -0700 Received: from turtle (turtle.dsi.unifi.it [150.217.15.61]) by dsiI.dsi.unifi.it (8.9.1b+Sun/8.9.1) with SMTP id JAA28691; Mon, 26 Apr 1999 09:48:00 +0200 (MET DST) Message-Id: <3.0.6.32.19990426095449.007d82f0@dsiI.dsi.unifi.it> X-Sender: vicario@dsiI.dsi.unifi.it X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 26 Apr 1999 09:54:49 +0200 To: pc@ee.nthu.edu.tw, int-serv@isi.edu, diff-serv@baynetworks.com, BM-List1@cs.ucdavis.edu, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comsoc-gicb@ieee.org, comsoc-tcii@ieee.org, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-teleservices@comp.lancs.ac.uk, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, end2end-interest@isi.edu, enternet@bbn.com, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, tcgn@ieee.org, hipparch@entropy.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, ietf@ietf.org, int-serv@isi.edu, isadsoc@fokus.gmd.de, itc@ieee.org, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, opensig-announce@ctr.columbia.edu, osimcast@bbn.com, performance@haven.epm.ornl.gov, prs@masi.ibp.fr, qosws@dstc.edu.au, qos-iso@mci.org.uk, rem-conf@es.net, reres@laas.fr, sc6wg4@ntd.comsat.com, sig-dce@opengroup.org, sigmedia@bellcore.com, tccc@ieee.org, testnet@canarie.ca, xtp-relay@cs.concordia.ca From: Enrico Vicario Subject: Tutorials by Sanjoy Paul at ICMCS99 Cc: vicario@dsi.unifi.it Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list dear colleague, as you know, ICMCS99 (the IEEE International Conference on Multimedia Computing and Systems) will take place in Florence in the week june 7-11, 1999. The opening day of the conference, june 7 (monday), is entirely devoted to TUTORIALS given by some of the major international scientists and researchers. Considering your specific area of activity, I would like to draw your attention on the tutorial given by SANJOY PAUL from Bell Labs entitled: "MULTICASTING ON THE INTERNET AND ITS APPLICATIONS TO MULTIMEDIA" (code T3A+T3B). Would you be interested in that, please fill up the form enclosed in the tail of this message and send it back to me by april 30. The full program of the tutorials and the conference is available at http://www.dsi.unifi.it/~icmcs99 . Looking forward to see you in Florence I send you my best regards Enrico Vicario IEEE ICMCS99 Tutorial Chair ------------------------------------- IEEE ICMCS99 International Conference on Multimedia Computing and Systems 1999 TUTORIALS REGISTRATION FORM 1) HALF DAY TUTORIALS FEES: ADVANCE REGISTRATION (until april 15, 1999) Ph.D. Students, Students ITL 250.000 IEEE Member ITL 320.000 Non-IEEE Member ITL 440.000 2) SELECTED TUTORIALS (*): Insert codes of tutorials you will attend (____) (____) The full list of titles is in the tail of this message. (*) We reserve the right to cancel a tutorial due to insufficient participation or other unforeseeable problem. People registered to a cancelled tutorial will be fully refunded with no processing fee. 3) REGISTRATION INFORMATION: Mark one (__) Dr. (__) Prof. (__) Mr. (__) Ms. (__) Mrs. Name:______________________________________________________________________ Last First Middle Initials Affiliation:_______________________________________________________________ _______________________________________________________________ IEEE Membership Number:____________________________________________________ Address:___________________________________________________________________ City:_____________________________________ State: ________Zip Code:________ Country:___________________________________________________________________ Telephone no.:________________________ Fax no.:____________________________ E-mail:____________________________________________________________________ Mailing lists: (__) do not include my personal data in a published list of attendees (__) do not include my personal data in a non-society mailing list --------------------------- ICMCS99 - TUTORIALS PROGRAM T3A --------------------------------------------------------------------------- "Multicasting on the Internet and its Applications to Multimedia - Part I" Sanjoy Paul. T3B "Multicasting on the Internet and its Applications to Multimedia - Part II" Sanjoy Paul. T5 ---------------------------------------------------------------------------- "Scheduling for Multimedia applications," A.L.Narasimha Reddy. T22 --------------------------------------------------------------------------- "Mpeg-7: Concepts, Terminology and Requirements," F.Nack, A.Steinmetz, W.Kriechbaum. T21 --------------------------------------------------------------------------- "Design and Analysis of Real Time and Multimedia Systems," A.M.K.Cheng. T14 --------------------------------------------------------------------------- "Intelligent Multimedia," M.T. Maybury. T24A -------------------------------------------------------------------------- "Model-based design of On-line and Off-line Multimedia Applications - Part I DESIGN," F.Garzotto, P.Paolini. T24B "Model-based evaluation of On-line and Off-line Multimedia Applications - Part II EVALUATION," M.F.Costabile, F.Garzotto, M.Matera. T13 --------------------------------------------------------------------------- "Advanced System Support for Electronic Business on Internet, with Emphasis on Industrial Case Studies," V.M.Milutinovic. T17 --------------------------------------------------------------------------- "Delivering Interactive Services over Digital TV (DTV) Infrastructure," M.Milenkovic T27 --------------------------------------------------------------------------- "Image Search Engines," A.Smeulders, T.Gevers. T10 --------------------------------------------------------------------------- "Indexing and Data Mining in Traditional and Multimedia Databases," C.Faloutsos. From rem-conf Mon Apr 26 09:00:26 1999 From rem-conf-request@es.net Mon Apr 26 09:00:24 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10bngv-0004nl-00; Mon, 26 Apr 1999 08:53:05 -0700 Received: from nixon.cs.odu.edu [128.82.4.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10bngu-0004nR-00; Mon, 26 Apr 1999 08:53:04 -0700 Received: from calvin.cs.odu.edu (gonza_a@calvin.cs.odu.edu [128.82.4.199]) by nixon.cs.odu.edu (8.9.3/8.9.3) with ESMTP id LAA07201 for ; Mon, 26 Apr 1999 11:53:20 -0400 (EDT) Received: from localhost (gonza_a@localhost) by calvin.cs.odu.edu (8.9.1/8.9.1) with ESMTP id LAA20658 for ; Mon, 26 Apr 1999 11:52:58 -0400 (EDT) X-Authentication-Warning: calvin.cs.odu.edu: gonza_a owned process doing -bs Date: Mon, 26 Apr 1999 11:52:58 -0400 (EDT) From: Agustin Gonzalez To: rem-conf@es.net Subject: Is there a standard for sending images? In-Reply-To: <3.0.5.32.19990420131214.01cf9d90@stardust.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Everyone, I have seen that video compression, such as H261, has been used for sending slides in mbone presentations. If you have joined any, you might agree that there is room for improvements. Sending the updates of a portion of a computer screen is different from sending video. Does anyone know of a standard for sending this type of images or works on this issue? Thanks, Agustin J. Gonzalez PhD Student Old Dominion University Norfolk, Virginia From rem-conf Mon Apr 26 09:14:08 1999 From rem-conf-request@es.net Mon Apr 26 09:14:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10bnyP-0005Ws-00; Mon, 26 Apr 1999 09:11:09 -0700 Received: from basil.cdt.luth.se [130.240.64.67] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10bnyN-0005WY-00; Mon, 26 Apr 1999 09:11:07 -0700 Received: from cdt.luth.se (blipp.cdt.luth.se [130.240.194.242]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id SAA13734; Mon, 26 Apr 1999 18:10:58 +0200 (MET DST) Message-ID: <3724903A.4EC3F6B5@cdt.luth.se> Date: Mon, 26 Apr 1999 18:11:38 +0200 From: Peter Parnes Organization: Centre for Distance-spanning =?iso-8859-1?Q?technology=2FLule=E5?= University of Technology, Marratech AB X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Agustin Gonzalez CC: rem-conf@es.net Subject: Re: Is there a standard for sending images? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I totally agree. For our net-based lectures here at the Centre for Distance-spanning Technology/CDT we use HTML slides instead. If _real_ HTML slides are being used then the client can adjust colors, fonts, sizes etc to fit their needs. It also saves loads of bandwidth as normal slide in HTML format takes just a few KB while a slide being transmitted using live H.261 takes much much much more bandwidth. HTML slides can easily be created from PowerPoint, Postscript or MagicPoint which are the three most common slide formats being used today (besides physical slides that is :-). There are several freeware and commercial applications available for transmitting shared Web pages using mcast. If video is supposed to be used in the future as well then I guess that H263+ with the Freeze option is a good start. It allows the sender to tell the client to freeze the current decoded frame until further video arrives. To handle packet loss and late commer the current frame could be repeated from time to time. But this is just my opinion ;-) /P From rem-conf Mon Apr 26 10:53:52 1999 From rem-conf-request@es.net Mon Apr 26 10:53:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10bpWM-0007Hy-00; Mon, 26 Apr 1999 10:50:18 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 10bpWJ-0007Hn-00; Mon, 26 Apr 1999 10:50:16 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 77F8D4CE02; Mon, 26 Apr 1999 13:50:09 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA01333; Mon, 26 Apr 1999 13:50:07 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.7/8.8.5) id NAA22133; Mon, 26 Apr 1999 13:49:53 -0400 (EDT) Message-Id: <199904261749.NAA22133@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: gonza_a@cs.odu.edu Subject: Re: Is there a standard for sending images? Cc: rem-conf@es.net References: <3724903A.4EC3F6B5@cdt.luth.se> Date: Mon, 26 Apr 1999 10:49:48 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >If _real_ HTML slides are being used ... [you get certain advantages] >HTML slides can easily be created from PowerPoint, Postscript or >MagicPoint... Don't these types of conversions generally make an image file of the slide, which negates the advantages of real HTML? If you're just creating image files and distributing them, you could try JPEG (perhaps with repetition-style redundancy). Bill From rem-conf Mon Apr 26 11:04:49 1999 From rem-conf-request@es.net Mon Apr 26 11:04:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10bpic-0007Xc-00; Mon, 26 Apr 1999 11:02:58 -0700 Received: from basil.cdt.luth.se [130.240.64.67] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10bpib-0007XO-00; Mon, 26 Apr 1999 11:02:57 -0700 Received: from cdt.luth.se (blipp.cdt.luth.se [130.240.194.242]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id UAA16193; Mon, 26 Apr 1999 20:02:12 +0200 (MET DST) Message-ID: <3724AA19.1224E173@cdt.luth.se> Date: Mon, 26 Apr 1999 20:02:01 +0200 From: Peter Parnes Organization: Centre for Distance-spanning =?iso-8859-1?Q?technology=2FLule=E5?= University of Technology, Marratech AB X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: gonza_a@cs.odu.edu, rem-conf@es.net Subject: Re: Is there a standard for sending images? References: <3724903A.4EC3F6B5@cdt.luth.se> <199904261749.NAA22133@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sure, you get a JPEG image. That is why I wrote "real HTML" in the paragraph before that. But even if you do create a JPEG image it is still only 20-50KB which should be compared to the 100-200 Kbps that is normally used for sending out video slides. /P From rem-conf Mon Apr 26 14:31:57 1999 From rem-conf-request@es.net Mon Apr 26 14:31:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10bsq3-0002qU-00; Mon, 26 Apr 1999 14:22:51 -0700 Received: from post.queensu.ca [130.15.126.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 10bsq2-0002qK-00; Mon, 26 Apr 1999 14:22:50 -0700 Received: from eleceng.ee.queensu.ca (eleceng.ee.queensu.ca [130.15.16.1]) by post.queensu.ca (8.9.0/8.9.0) with SMTP id RAA02503; Mon, 26 Apr 1999 17:21:24 -0400 (EDT) Received: from htm5.queensu.ca by eleceng.ee.queensu.ca (4.1/SMI-4.1) id AA02798; Mon, 26 Apr 99 17:21:24 EDT Received: by htm5.queensu.ca (4.1/SMI-4.1) id AA04370; Mon, 26 Apr 99 17:21:15 EDT Date: Mon, 26 Apr 1999 17:21:10 -0400 (EDT) From: Hussein Mouftah X-Sender: mouftah@htm5 To: multicomm@research.panasonic.com, multicomm@cc.bellcore.com, csim@comsoc.org, comswtc@comsoc.org, atm@bbn.com, ieeetcpc@ccvm.sunysb.edu, hipparch@sophia.inria.fr, rem-conf@es.net, commsoft@cc.bellcore.com, tccc@ieee.org, ietf@cnri.reston.va.us, rahman-mh@rmc.ca Cc: plyons@events.kingston.net Subject: IEEE BSS'99 Technical Program Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IEEE BSS '99 3rd IEEE International Workshop on Broadband Switching Systems Kingston, Ontario, Canada, June 1-3, 1999 The goal of this workshop is to provide an effective forum for discussing new directions, new challenges, new opportunities, and new advances on Broadband Switching Systems, and to foster communications among researchers and engineers from both academia and industry with a common interest in improving Broadband Switching Systems. The Technical Program contains two tutorials and eight sessions as follows: Tutorial 1: June 1st, 1999, 8:30am-12:00pm Title: Photonic Switching Technology Instructors: Prof. Hussein Mouftah (Queen's University, Canada) and Prof. Jaafar Elmirghani (University of Northumbria, Newcastle, UK) Tutorial 2: June 1st, 1999, 1:30pm-5:00pm Title: Multiservice Optical IP Networking Instructor: Prof. Andrzej Jajszczyk (ATR and ITTI, Poland) There are eight technical sessions over the following two days covering the following topics: Switch Architectures, Broadband IP, Performance Evaluation, Multicasting, Photonic Networks, Network Access and Implementations. Details of the technical program and information on registration, travel and accomodation can be found at: http://www.events-management.com/bss'99/bss99.htm See You There... From rem-conf Mon Apr 26 14:44:01 1999 From rem-conf-request@es.net Mon Apr 26 14:44:00 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10bt99-0003dC-00; Mon, 26 Apr 1999 14:42:35 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10bt98-0003d1-00; Mon, 26 Apr 1999 14:42:34 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id OAA26914; Mon, 26 Apr 1999 14:42:32 -0700 (PDT) Message-Id: <3.0.3.32.19990426144231.00aff3b0@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 26 Apr 1999 14:42:31 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: Berkeley MIG Seminar now available with Real Networks Streaming Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi - For the past four years we have broadcast the "Berkeley Multimedia, Interfaces, and Graphics Seminar" every wednesday world-wide using the Internet Mbone. Beginning this week we will simulcast this semianr using the Real Networks G2 System. The RN technology allows viewers to connect using a unicast stream so you do not have to download the Mbone tools and worry about access to IP-Multicast and the Mbone. The seminar will be Wednesday April 28, 1999 from 1.10 to 2.30 Pacific Daylight Time. You can connect to the live RN broadcast at http://media1.bmrc.berkeley.edu:8080/ramgen/encoder/cs298-5.rm You can download the free G2 Player required to view this broadcast at the following sites: Macintosh... http://www.real.com/products/player/50player/index.html?src=dlbutton_all,990 309choice_1,wiqfx0217 Windows [WNT/W95/W98]... http://www.real.com/products/player/downloadrealplayer.html?wp=dl0199&src=dl button_all,990309choice_1&lang=en You can get further information abut this seminar at the MIG Seminar web page at http://bmrc.berkeley.edu/mig The seminar this week will be: 4/28/99 "Why understanding anything about the Internet is painfully hard" by Vern Paxson We will continue to broadcast using the Mbone technology because it allows us to broadcast several windows at the same time (i.e., one on the speaker or audience and one on the presentation material taken from a PC, an overhead camera stand for transparencies, or a VCR). The RN broadcast will switch all video sources into one stream for now. Larry p.s. For further information on the distance learning programs we are developing at Berkeley, see http://bmrc.berkeley.edu/bibs. -- Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU Computer Science Division - EECS Phone: 510-642-5117 University of California, Berkeley Fax: 510-642-5615 Berkeley, CA 94720-1776 URL: http://bmrc.berkeley.edu/~larry From rem-conf Mon Apr 26 17:09:59 1999 From rem-conf-request@es.net Mon Apr 26 17:09:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10bvOO-0005lF-00; Mon, 26 Apr 1999 17:06:28 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10bvON-0005l5-00; Mon, 26 Apr 1999 17:06:27 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id RAA27559; Mon, 26 Apr 1999 17:06:25 -0700 (PDT) Message-Id: <3.0.3.32.19990426170623.00aff960@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 26 Apr 1999 17:06:23 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: Erata: Berkeley MIG announcement Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To tune into the live Real Networks broadcast of this weeks Berkeley Multimedia Interfaces and Graphics session, connect to: http://bmrc.berkeley.edu/mig/live.ram 4/28/99 "Why understanding anything about the Internet is painfully hard" by Vern Paxson From rem-conf Mon Apr 26 17:32:41 1999 From rem-conf-request@es.net Mon Apr 26 17:32:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10bvmR-0006iK-00; Mon, 26 Apr 1999 17:31:19 -0700 Received: from henry.newn.cam.ac.uk [131.111.204.130] (root) by mail1.es.net with smtp (Exim 1.81 #2) id 10bvmP-0006hm-00; Mon, 26 Apr 1999 17:31:17 -0700 Received: from unnny by henry.newn.cam.ac.uk with smtp (Smail3.1.29.1 #33) id m10bvnq-000IjpC; Tue, 27 Apr 99 01:32 BST Message-Id: From: "Victor" Subject: That's it To: joinus833u@es.net X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Mon, 26 Apr 1999 19:18:45 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list =46REE E-COMMERCE I=46 YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: You host your site with us and you get free E-Commerce, including a merchant account, real-time software and shopping cart. You have never seen a package deal like this before: - Your own merchant account with one of the lowest rates in the industry - Accept VISA, MASTER, AMEX and DISCOVER - Direct deposit within 48 hrs into your checking account - Shopping Cart store front software with an easy to use web based interface - Real-Time Credit Card Processing software - Virtual terminal for phone/fax/mail orders - E-mail receipts - Recurring billing feature - Password generation for membership sites - Automatic batch closing - Address verification system (AVS) - Back office to 24/7 access account history - 50 MB (megabytes) of disk space - 10 GB (gigabyte) of data transfer per month - 15 POP3 E-mail accounts - Unlimited alias E-mail addresses - Your own E-mail server - Live web site statistics - Unlimited =46TP uploads - Anonymous =46TP - Telnet access (UNIX) - CGI directory for your own scripts - Site control panel - Installation included - Tech support included All this and more for ONLY $69.95 per month and a one time set up fee of $149.00. NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. Request our free E-mail information by replying to: mailto:v195@mailme.net?subject=3DE-PACKAGE ********************************************************************* *** Remove at mailto:tony1@techscout.com?subject=3Dremove ********************************************************************* *** From rem-conf Tue Apr 27 05:21:10 1999 From rem-conf-request@es.net Tue Apr 27 05:21:10 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10c6lW-0005EE-00; Tue, 27 Apr 1999 05:15:06 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10c6lU-0005Do-00; Tue, 27 Apr 1999 05:15:04 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07987; Tue, 27 Apr 1999 08:14:00 -0400 (EDT) Message-Id: <199904271214.IAA07987@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mib-05.txt Date: Tue, 27 Apr 1999 08:14:00 -0400 Sender: nsyracus@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Real-Time Transport Protocol Management Information Base Author(s) : M. Baugher, I. Suconick, B. Strahm Filename : draft-ietf-avt-rtp-mib-05.txt Pages : 31 Date : 26-Apr-99 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Protocol(RTP) systems [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990426134728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990426134728.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Apr 27 09:39:08 1999 From rem-conf-request@es.net Tue Apr 27 09:39:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10cAmZ-0000Le-00; Tue, 27 Apr 1999 09:32:27 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 10cAmY-0000LU-00; Tue, 27 Apr 1999 09:32:26 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id JAA29551; Tue, 27 Apr 1999 09:32:25 -0700 (PDT) Message-Id: <3.0.3.32.19990427093224.00b02880@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 27 Apr 1999 09:32:24 -0700 To: bmrc-list@gumby.CS.Berkeley.EDU From: Florissa Colina Subject: 4/28 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Why Understanding Anything About the Internet is Painfully Hard Wednesday April 28, 1999, 1:00-2:30 p.m. 405 Soda Hall Please note the time frame of the seminar series has changed!! Vern Paxson AT&T Center for Internet Research at ICSI The Internet poses immense challenges when attempting to measure, model, analyze, or extend it. The underlying problems are that the network is tremendously diverse, such that the notion of "typical" is rarely anything but misleading; it grows explosively, and has been doing so for years; and the traditional network modeling framework, based on Poisson assumptions of independence or at most weak traffic correlations, lies in ruins, destroyed by overwhelming measurement evidence. We sketch the fundamental causes of these difficulties and some of the strategies researchers have devised for coping with them. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/mig/live.ram To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: video -- 224.2.163.7/57076 audio -- 224.2.147.61/27202 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://bmrc.berkeley.edu/mig Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Apr 27 10:37:24 1999 From rem-conf-request@es.net Tue Apr 27 10:37:23 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10cBid-0001Xm-00; Tue, 27 Apr 1999 10:32:27 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 10cBiZ-0001X6-00; Tue, 27 Apr 1999 10:32:23 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23815; Tue, 27 Apr 1999 13:31:17 -0400 (EDT) Message-Id: <199904271731.NAA23815@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-format-guidelines-02.txt,.ps Date: Tue, 27 Apr 1999 13:31:17 -0400 Sender: nsyracus@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Guidelines for Writers of RTP Payload Format Specifications Author(s) : M. Handley, C. Perkins Filename : draft-ietf-avt-rtp-format-guidelines-02.txt,.ps Pages : 9 Date : 26-Apr-99 This document provides general guidelines aimed at assisting the authors of RTP [9] 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-format-guidelines-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-format-guidelines-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-format-guidelines-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990426142527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-format-guidelines-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-format-guidelines-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990426142527.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Apr 27 16:57:50 1999 From rem-conf-request@es.net Tue Apr 27 16:57:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10cHdE-0006Ib-00; Tue, 27 Apr 1999 16:51:16 -0700 Received: from acsys.anu.edu.au [150.203.20.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 10cHd8-0006Gy-00; Tue, 27 Apr 1999 16:51:14 -0700 Received: from accordion (accordion.anu.edu.au [150.203.20.58]) by acsys.anu.edu.au (8.9.1/8.9.1) with SMTP id JAA02676; Wed, 28 Apr 1999 09:49:51 +1000 (EST) Message-Id: <3.0.32.19990428095019.00a01e60@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 28 Apr 1999 09:50:21 +1000 To: Peter Parnes , Bill Fenner From: Markus Buchhorn Subject: Re: Is there a standard for sending images? Cc: gonza_a@cs.odu.edu, rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 20:02 26/04/99 +0200, Peter Parnes wrote: >Sure, you get a JPEG image. That is why I wrote "real HTML" in the >paragraph before that. But even if you do create a JPEG image it is >still only 20-50KB which should be compared to the 100-200 Kbps that is >normally used for sending out video slides. In seminars like the Berkeley Multimedia, which are very professionally done IMHO, they use two video streams, one for the speaker and one for the slides. I have never seen 100-200kb/s from the slides even during transitions - because they limit the rate for the slides to something small (10's of kb/s) which is only a slight issue during a slide transition. That is a design decision at the source of the video. But on top of that, what is wrong with H.261 for still images? If there is zero or little change in the image then the bandwidth required rapidly drops away to ~3kb/s or less, which is ~20kB/min, about the typical time a slide is shown. It helps a lot to take the video directly from the projector/computer, rather than off the projected image (to miminise light-level fluctuations), again this is a design decision. Also, as noted before, this way you have a continuous feed to handle packet loss and new group members, unlike a one-time transmission of a still. Now, I agree if your slide is predominantly text (html) then it's far better to compress in the alphanumeric domain than the bitmap domain. So what you really want is an intelligent video viewer which handles images in some format (jpeg, h.261, gif) and text as a separate AV type, and rebuilds the slide structure using the two data types. Something between vic and wb and mMosaic.... And of course we have to get decent HTML/XML+DTD out of Powerpoint and its ilk :-) Anyway - back into my cave now ;-) Cheers, Markus Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 From rem-conf Tue Apr 27 22:50:47 1999 From rem-conf-request@es.net Tue Apr 27 22:50:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10cNB8-0002aS-00; Tue, 27 Apr 1999 22:46:38 -0700 Received: from proxy3.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 10cNB6-0002aI-00; Tue, 27 Apr 1999 22:46:36 -0700 Received: from mg136-133.ricochet.net (mg136-133.ricochet.net [204.179.136.133]) by proxy3.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id WAA29179 for ; Tue, 27 Apr 1999 22:46:13 -0700 (PDT) Message-Id: <3.0.5.16.19990427213220.2f5f1952@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Tue, 27 Apr 1999 21:32:20 To: rem-conf@es.net From: Ross Finlayson Subject: ALF in action Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You'll recall that in the Minneapolis IETF, I described a new RTP payload format for MP3 audio that - by following Application Layer Framing principles - tolerates packet loss better than the existing standard (RFC 2250). At the meeting I was somewhat reticent about the benefits of this new format, because at the time I had yet to evaluate it with a real example. I've now had a chance to do this, and the benefits are quite striking. At I illustrate this with three MP3 files: 1/ An original MP3 file (i.e., with no loss) 2/ The same data, with random (Poisson) 10% frame loss. (This is similar to what you hear when a RFC 2250 stream encounters packet loss.) 3/ The same data, with the same loss pattern, but with the losses applied to *ADUs* rather than frames. (This is similar to what you'd hear using the new payload format.) Those of you who are teaching students about ALF may wish to point them at this page. It's a nice illustration of how a data stream can be made more loss-tolerant merely by changing the way it is framed. Ross. From rem-conf Wed Apr 28 21:16:58 1999 From rem-conf-request@es.net Wed Apr 28 21:16:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ci1T-0001EU-00; Wed, 28 Apr 1999 21:02:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 10ci1R-0001EK-00; Wed, 28 Apr 1999 21:02:02 -0700 Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Apr 29 00:00:18 EDT 1999 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.250.95]) by couch.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id AAA19151; Thu, 29 Apr 1999 00:00:14 -0400 (EDT) Message-ID: <3727D955.17D03CE1@dnrc.bell-labs.com> Date: Thu, 29 Apr 1999 00:00:21 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: rem-conf@es.net, Stephen Casner , Colin Perkins , Henning Schulzrinne , Mark Handley Subject: Usage of SDP with FEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At the last AVT meeting, we discussed the usage of SDP when the FEC payload format is in use. At the time, I suggested using a separate media stream (different m line) in the SDP to convey information on the FEC stream. Then, I proposed a tag attribute to indicate which media stream the FEC stream was protecting. The consensus was that this is not a good idea. Rather, the FEC information should be indicated within the m section of the media it protects. The application is similar to the hierarchical coded video. I looked at the SDP for supporting hierarchically encoded video, but it does not completely support our needs. It has the following issues: 1. You can include multiple c lines, each with a different multicast address, within a media section. For hierarchical video, each refers to a different layer. For FEC, we could send two c lines, one referring to the original media, and one the FEC. However, I could find nothing in rfc2327 which indicates how a receiver knows which layer is the base, and which are enhancements. In our case, I think its desirable to indicate which c line is the actual media, and which is the FEC. Presumably the receiver could know by joining the group, and looking at the payload type. But, for bandwidth restricted links, I think you'd like to know ahead of time. Am I missing something in SDP which conveys this? Is it implicit (first c line = base layer)? 2. Instead of multiple c lines, you can have multiple ports in the m line, using the slash: m=audio 986/2 RTP/AVP 0 88 We could use this to allow the FEC and audio on separate ports. But, this mechanism only allows the audio and FEC on consecutive (consecutive even, to be precise) ports. This is somewhat restricive. Do we care? As with the address case, which port is the FEC, and which is the audio? 3. SDP explicitly says for hierarchical video, there is no way for the layers to be on different ports AND multicast groups. Again, it would seem desirable to allow the FEC on a separate address and port. 4. Finally, if we directly use the hierarchical video mechanisms, how does the recipient of the SDP know that we are talking about this FEC mechanism, and not hierachical video? What do we do if the session has BOTH? My proposal, in the interests of backwards compatibility, is to accept the restrictions (separate groups or separate consecutive ports). I also think that we should add an attribute which indicates which address (or port) the FEC is on, and which address (or port) is being protected. So, for example: m=audio 44/2 RTP/AVP 0 34 a=rtpmap:34 parityfec c=IN IP4 224.3.2.1 a=fec:1 2 This indicates there are two ports: 44 and 46, on group 224.3.2.1. The FEC is protecting the first port (the 1 in a=fec:1 2) and appears on the second (the 2 in a=fec:1 2). Another example: m=audio 44 RTP/AVP 0 34 a=rtpmap:34 parityfec c=IN IP4 123.3.4.5 c=IN IP4 123.4.4.4 a=fec:2 1 This indicates there are two unicast addresses. The FEC is protecting the audio on the second port (123.4.4.4), and the FEC itself comes on 123.3.4.5. A more complex example: m=audio 44 RTP/AVP 22 34 a=rtpmap:34 parityfec a=rtpmap:22 some-hierarchical-video-codec c=IN IP4 224.4.5.6/127/8 a=fec:1 8 This indicates a case where there is both hierarchical video and FEC are present. The video appears on groups 224.4.5.6 - 224.4.5.12. The FEC protects the first group (the base layer), and appears on the last group, 224.4.5.13. Comments on this proposal? Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Apr 29 02:08:50 1999 From rem-conf-request@es.net Thu Apr 29 02:08:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10cmjn-0004Bf-00; Thu, 29 Apr 1999 02:04:07 -0700 Received: from individual.eunet.pt (mail.EUnet.pt) [193.126.4.67] by mail1.es.net with esmtp (Exim 1.81 #2) id 10cmjl-0004BV-00; Thu, 29 Apr 1999 02:04:06 -0700 Received: from urano ([193.126.234.218]) by mail.EUnet.pt (8.9.1/8.9.1) with SMTP id KAA04093 for ; Thu, 29 Apr 1999 10:04:02 +0100 (WET DST) Date: Thu, 29 Apr 1999 10:04:02 +0100 (WET DST) From: info@gargalhadas.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable To: rem-conf@es.net Subject: Rir nao paga impostos Message-ID: X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Priority: 3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Caros cibernautas, Tenho a dar uma optima novidade: existe um site inteiramente interactivo= de = =0A anedotas em Portugues em HTTP://WWW.GARGALHADAS.COM . O site esta' rech= eadissimo de anedotas repartidas por inumeras categorias: loiras, cumulos,= variados, adivinhas, pensamentos e imagens. Se quiseres contar uma anedota= podes faze-lo atraves do forum do HTTP://FORUM.GARGALHADAS.COM . Podes con= tar as anedotas que quiseres, e mais: elas serao votadas por todos aqueles= que as lerem. Mais tarde sera' criado um espaco onde essas anedotas serao= distinguidas na primeira pagina e quem sabe ate' premiadas. Por isso nao= percas mais tempo e visita ja' o HTTP://WWW.GARGALHADAS.COM. = =0A Um abraco, WebMaster do Gargalhadas.com http://www.gargalhadas.com http://forum.gargalhadas.com From rem-conf Thu Apr 29 08:55:30 1999 From rem-conf-request@es.net Thu Apr 29 08:55:29 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10ct23-0007VO-00; Thu, 29 Apr 1999 08:47:23 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 10ct21-0007VE-00; Thu, 29 Apr 1999 08:47:22 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 29 Apr 1999 16:47:16 +0100 To: rem-conf@es.net Subject: Working group last call on the RTP MIB cc: casner@cisco.com, bill.strahm@intel.com Date: Thu, 29 Apr 1999 16:47:15 +0100 Message-ID: <2729.925400835@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At the AVT meeting in Minneapolis, we noted that the RTP MIB was almost complete and would be ready for last call after a couple of minor issues were resolved. These issues have now been resolved, and a new version of the draft (draft-ietf-avt-rtp-mib-05.txt) is available. Accordingly, this message is to announce a working group last call on the RTP MIB. If no comments requiring changes are received in the next two weeks (by 14th May), this draft will be submitted for publication as a proposed standard. Colin From rem-conf Thu Apr 29 12:09:57 1999 From rem-conf-request@es.net Thu Apr 29 12:09:57 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10cw7Q-0002NB-00; Thu, 29 Apr 1999 12:05:08 -0700 Received: from mail-green.research.att.com [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 10cw7O-0002N1-00; Thu, 29 Apr 1999 12:05:06 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id E7A5B1E009; Thu, 29 Apr 1999 15:05:01 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA04277; Thu, 29 Apr 1999 15:05:00 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.7/8.8.5) id PAA18799; Thu, 29 Apr 1999 15:05:00 -0400 (EDT) Message-Id: <199904291905.PAA18799@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bill.strahm@intel.com, mbaugher@intel.com, isuconick@videoserver.com Subject: Re: Working group last call on the RTP MIB Cc: rem-conf@es.net, casner@cisco.com, c.perkins@cs.ucl.ac.uk Date: Thu, 29 Apr 1999 12:04:59 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Here are some comments on draft-05. Some of these may be ignorance on my part, due to my lack of involvement in the evolution of the MIB. One general comment is that the text 'RTP: A Transport Protocol for Real-Time Applications' follows about 50% of the references to RFC1889. I'm not sure that RFC1889's title needs to be repeated so many times throughout the document. The indentation of the DESCRIPTIONs for rtpSessionIfIndex and rtpRcvrEntry are weird. rtpSessionIfIndex refers to the "Internet Standard MIB". Should this reference have an RFC reference attached to it, since there are lots of MIBs that are Internet Standards? In the DESCRIPTION of rtpSessionReceiverJoins, I'd suggest parallelism with the description of rtpSessionSenderJoins by saying ...created (rtpSessionSartTime). A receiver 'joins' an RTP session by sending RTCP packets to it. Receivers that... and removing the last sentence. rtpSessionMonitor is read-only. What should an application that is normally just a receiver but has the capability of monitoring if desired do - it seems like it would make sense to be able to write to this value (conditionally implemented, of course). In the RtpSenderEntry and RtpRcvrEntry sequences, there exist objects rtpSRs and rtpRRs. I think for parallelism with the rest of the table these should be rtpSenderSRs and rtpRcvrRRs. I realize that expanding the acronym ends up being "RTP Sender Sender Reports", but the next object in each sequence is "rtpSenderSRTime" and "rtpRcvrRRTime", so it's even self-inconsistent. The MIB specifies a DisplayString for the sender's and receiver's CNAME and Tool. However, the RTP spec says that SDES items are encoded using UTF-8. Although it suggests that CNAME should be in ASCII it doesn't seem to require it, and there is no such restriction for the Tool. Therefore, what should agents do when they get RTP CNAMEs or TOOLs that are not representable as DisplayStrings? The description of rtpSenderPackets, rtpSenderOctets, and rtpSRs do not include receiving hosts (just senders and monitors), but these values can be known by receiving hosts (and rtpSenderSRTime mentions receiving hosts). I think that receiving hosts should be explicitly mentioned for each of these objects. Maybe this is showing my ignorance of SNMP, but rtpSenderTool and rtpRcvrTool have DEFVAL clauses of { ''H }. The ''H syntax describes a hex string, but there's no hex string specified, so I think this is the same as { "" }, which is likely to be easier to understand for people who don't know what the H suffix means. In addition, the comment says "Null if not available" -- the word "Null" may have different meanings to different people; some might interpret it as { '00'H } while others might interpret it as { "" } (i.e. a string containing a single null byte vs. an empty string). I'd suggest that the comment read "Empty if not available", if that is actually what is meant. In the description for rtpSenderPT, "static or dynamic payload type" is redundant - all payload types are either static or dynamic. I'd just describe it as "Payload type". rtpRcvrAddr may not be known by a monitor if it receives the RR through a mixer or translator. It should be noted that this may be 0.0.0.0 (or some other designated "unknown" value) if the receiver is beyond a mixer or translator, or that it may be the mixer or translator's address and not necessarily the receiver's. Regarding rtpRcvrPT - I'm at a total loss on this one. The payload type of what RTP packets? Receivers don't send RTP, that's why they're receivers and not senders. Bill From rem-conf Thu Apr 29 15:20:54 1999 From rem-conf-request@es.net Thu Apr 29 15:20:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10cz8M-00054j-00; Thu, 29 Apr 1999 15:18:18 -0700 Received: from ganymede.or.intel.com [134.134.248.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 10cz8G-00054R-00; Thu, 29 Apr 1999 15:18:13 -0700 Received: from orsmsx29.jf.intel.com (orsmsx29.jf.intel.com [192.168.65.29]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id WAA17005; Thu, 29 Apr 1999 22:18:09 GMT Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 29 Apr 1999 15:18:08 -0700 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB201362DCA@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'Bill Fenner'" , "Strahm, Bill" , "Baugher, Mark" , isuconick@videoserver.com Cc: rem-conf@es.net, casner@cisco.com, c.perkins@cs.ucl.ac.uk Subject: RE: Working group last call on the RTP MIB Date: Thu, 29 Apr 1999 15:18:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I will provide some rough comments below. I will meet with the other authors to determine what we will do about them, and if they agree with what I have outlined below Based on my comments below, if they are considered acceptable, I don't think we will have to restart Last Call with a new draft. Bill -----Original Message----- From: Bill Fenner [mailto:fenner@research.att.com] Sent: Thursday, April 29, 1999 12:05 PM To: bill.strahm@intel.com; mbaugher@intel.com; isuconick@videoserver.com Cc: rem-conf@es.net; casner@cisco.com; c.perkins@cs.ucl.ac.uk Subject: Re: Working group last call on the RTP MIB Here are some comments on draft-05. Some of these may be ignorance on my part, due to my lack of involvement in the evolution of the MIB. One general comment is that the text 'RTP: A Transport Protocol for Real-Time Applications' follows about 50% of the references to RFC1889. I'm not sure that RFC1889's title needs to be repeated so many times throughout the document. [Bill Strahm responds]Possibly, however most of the references happen in a Description clause where a "end user" may not have seen any of the rest of the document. If this is their only exposure, it is important that we have the whole reference here... The indentation of the DESCRIPTIONs for rtpSessionIfIndex and rtpRcvrEntry are weird. [Bill Strahm responds] Fixed... darn tabs, thought I had gotten them all out, thanks rtpSessionIfIndex refers to the "Internet Standard MIB". Should this reference have an RFC reference attached to it, since there are lots of MIBs that are Internet Standards? [Bill Strahm responds] You are correct. See if you like this better "The ifIndex value is set to the corresponding value from MIB-II (See RFC 1213, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II). This is the interface that the RTP stream is being sent to or received from, or in the case of an RTP Monitor the interface that RTCP packets will be received on. Cannot be changed if rtpSessionRowStatus is 'active'." In the DESCRIPTION of rtpSessionReceiverJoins, I'd suggest parallelism with the description of rtpSessionSenderJoins by saying ...created (rtpSessionSartTime). A receiver 'joins' an RTP session by sending RTCP packets to it. Receivers that... and removing the last sentence. [Bill Strahm responds] Good point. Corrected text is (I decided to make it sending Receiver Reports to the Session, people might get confused if a Sender Sends a Sender RTCP report to the session, should that be counted as a receiver... The answer is NO) created (rtpSessionStartTime). A receiver 'joins' an RTP session by sending RTCP Receiver Reports to the session. Receivers that leave and then re-join following an RTCP BYE rtpSessionMonitor is read-only. What should an application that is normally just a receiver but has the capability of monitoring if desired do - it seems like it would make sense to be able to write to this value (conditionally implemented, of course). [Bill Strahm responds] The value of this Object is set by the agent based on how the row was created. If the row was created by a management station it is set to TRUE. If it is created by the rtp Host in response to a new RTP session being sent or received by the host, it is set to FALSE. It is not meant to be used to determine what the behavior of a host system is. I am proposing no changes here In the RtpSenderEntry and RtpRcvrEntry sequences, there exist objects rtpSRs and rtpRRs. I think for parallelism with the rest of the table these should be rtpSenderSRs and rtpRcvrRRs. I realize that expanding the acronym ends up being "RTP Sender Sender Reports", but the next object in each sequence is "rtpSenderSRTime" and "rtpRcvrRRTime", so it's even self-inconsistent. [Bill Strahm responds] Correct, changed The MIB specifies a DisplayString for the sender's and receiver's CNAME and Tool. However, the RTP spec says that SDES items are encoded using UTF-8. Although it suggests that CNAME should be in ASCII it doesn't seem to require it, and there is no such restriction for the Tool. Therefore, what should agents do when they get RTP CNAMEs or TOOLs that are not representable as DisplayStrings? [Bill Strahm responds] You are correct. Changed from DisplayString to OCTET STRING The description of rtpSenderPackets, rtpSenderOctets, and rtpSRs do not include receiving hosts (just senders and monitors), but these values can be known by receiving hosts (and rtpSenderSRTime mentions receiving hosts). I think that receiving hosts should be explicitly mentioned for each of these objects. [Bill String responds] Just to confuse you, a receiving host does not have to have the Sender table entry at all, and if it does, it is acting in a monitor mode (This is the hardest concept of the MIB, host mode means the data in the MIB is coming directly from the host implementation, monitor mode means the data is coming from RTCP reports) Maybe this is showing my ignorance of SNMP, but rtpSenderTool and rtpRcvrTool have DEFVAL clauses of { ''H }. The ''H syntax describes a hex string, but there's no hex string specified, so I think this is the same as { "" }, which is likely to be easier to understand for people who don't know what the H suffix means. In addition, the comment says "Null if not available" -- the word "Null" may have different meanings to different people; some might interpret it as { '00'H } while others might interpret it as { "" } (i.e. a string containing a single null byte vs. an empty string). I'd suggest that the comment read "Empty if not available", if that is actually what is meant. [Bill Strahm responds] I'll have to get back on you with this one. I believe we are correct here, but I will have to think about it In the description for rtpSenderPT, "static or dynamic payload type" is redundant - all payload types are either static or dynamic. I'd just describe it as "Payload type". [Bill Strahm responds] Fair enough, changed rtpRcvrAddr may not be known by a monitor if it receives the RR through a mixer or translator. It should be noted that this may be 0.0.0.0 (or some other designated "unknown" value) if the receiver is beyond a mixer or translator, or that it may be the mixer or translator's address and not necessarily the receiver's. [Bill Strahm responds] Try this alternative wording "The unicast transport address of the receiver. In the case of an RTP Monitor this address will be the address that the RTCP Packet is received from" Again realize the difference between a receiving host (that will ALWAYS know its address) and a monitor that might be an RTP sender relying on RTCP packets to fill in this table. Regarding rtpRcvrPT - I'm at a total loss on this one. The payload type of what RTP packets? Receivers don't send RTP, that's why they're receivers and not senders. [Bill Strahm responds] This is the payload type of the packets being received. Realize that an RTP receiver does not have to include a rtpSenderEntry, so this data is here Bill From rem-conf Thu Apr 29 16:23:33 1999 From rem-conf-request@es.net Thu Apr 29 16:23:32 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10d06k-0006GU-00; Thu, 29 Apr 1999 16:20:42 -0700 Received: from mail-green.research.att.com [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 10d06j-0006GK-00; Thu, 29 Apr 1999 16:20:41 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 894E81E003; Thu, 29 Apr 1999 19:20:39 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA10175; Thu, 29 Apr 1999 19:20:38 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.7/8.8.5) id TAA20942; Thu, 29 Apr 1999 19:20:37 -0400 (EDT) Message-Id: <199904292320.TAA20942@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bill.strahm@intel.com Subject: RE: Working group last call on the RTP MIB Cc: fenner@research.att.com, mbaugher@intel.com, isuconick@videoserver.com, rem-conf@es.net, casner@cisco.com, c.perkins@cs.ucl.ac.uk Date: Thu, 29 Apr 1999 16:20:36 -0700 Versions: dmail (solaris) 2.2c/makemail 2.8t X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Re having the full name of RFC1889 in lots of Descriptions - I don't feel strongly about this; leaving it as is is OK with me. rtpSessionEntry is also indented funny, missed this the first time around. > "The ifIndex value is set to the corresponding value > from MIB-II (See RFC 1213, "Management Information > Base for Network Management of TCP/IP-based internets: > MIB-II). This is the interface that the RTP stream is > being sent to or received from, or in the case of an RTP > Monitor the interface that RTCP packets will be received > on. Cannot be changed if rtpSessionRowStatus is 'active'." Much better, thanks. > created (rtpSessionStartTime). A receiver 'joins' an RTP > session by sending RTCP Receiver Reports to the session. > Receivers that leave and then re-join following an RTCP BYE Also better. With respect to whether or not rtpSessionMonitor is read-only, let me bring up the larger point - what about multiple RTP instances on the same session? (e.g. a receiver and a monitor) Do we end up with multiple entries in the rtpSessionTable, some created by the RTP applications and some created by management and multiple rows with the same info except one has rtpSessionMonitor false and the other true? (Actually, I guess that works, doesn't it.) >Just to confuse you, a receiving host does not have >to have the Sender table entry at all, and if it does, it is acting in a >monitor mode (This is the hardest concept of the MIB, host mode means the >data in the MIB is coming directly from the host implementation, monitor >mode means the data is coming from RTCP reports) Ugh. You're right, you succeeded in confusing me. Your first sentence contradicts the description of rtpSenderTable (it says "RTP receiving hosts MAY have an entry in this table ..." -- note typo there, the document says "reveiving"); that implies that a receiving host may populate the sender table without having to be a monitor. If a receiving host should not create entries in the rtpSenderTable, then receiving hosts should be removed from the description of rtpSenderTable and rtpSenderSRTime. However, I think that the description of rtpSenderTable should remain with the ...MAY... and the rtpSenderPackets, Octets and SRs should talk about hosts in the same way as monitors. >[about DEFVAL of { ''H } vs. { "" }] >[Bill Strahm responds] I'll have to get back on you with this one. I >believe we are correct here, but I will have to think about it My reading of rfc2578 is that ''H is used for numbers (although it makes sense for OCTET-STRINGS too). "" is used for character strings, which makes more sense in my mind for a DisplayString. Now that these are octet-strings, maybe ''H is more correct. > "The unicast transport address of the receiver. In the case of > an RTP Monitor this address will be the address that the RTCP > Packet is received from" Sounds good. Another description that could use some wording changes is rtp{Sender,Rcvr}Tool. Something like "The value placed in (if sender) or received in (if receiver/monitor) RTCP SDES TOOL field" might be more clear. Bill From rem-conf Fri Apr 30 00:28:09 1999 From rem-conf-request@es.net Fri Apr 30 00:28:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10d7UC-0001ui-00; Fri, 30 Apr 1999 00:13:24 -0700 Received: from agora.rdrop.com [199.2.210.241] by mail1.es.net with esmtp (Exim 1.81 #2) id 10d7UB-0001uW-00; Fri, 30 Apr 1999 00:13:23 -0700 Received: from s.brower (ppp-d0.rdrop.com [199.2.212.33]) by agora.rdrop.com (8.8.5/8.8.5) with SMTP id AAA10099; Fri, 30 Apr 1999 00:13:12 -0700 (PDT) Message-Id: <3.0.32.19990430001551.006eb334@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 30 Apr 1999 00:15:53 -0700 To: fenner@research.att.com From: Mark Baugher Subject: Re: Working group last call on the RTP MIB Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bill, > One general comment is that the text 'RTP: A Transport Protocol for > Real-Time Applications' follows about 50% of the references > to RFC1889. > I'm not sure that RFC1889's title needs to be repeated so many times > throughout the document. I agree. > > The MIB specifies a DisplayString for the sender's and > receiver's CNAME > and Tool. However, the RTP spec says that SDES items are > encoded using > UTF-8. Although it suggests that CNAME should be in ASCII it doesn't > seem to require it, and there is no such restriction for the Tool. > Therefore, what should agents do when they get RTP CNAMEs or > TOOLs that > are not representable as DisplayStrings? Thanks for finding this bug. > > Maybe this is showing my ignorance of SNMP, but rtpSenderTool and > rtpRcvrTool have DEFVAL clauses of { ''H }. The ''H syntax > describes a > hex string, but there's no hex string specified, so I think > this is the > same as { "" }, which is likely to be easier to understand for people > who don't know what the H suffix means. In addition, the comment says > "Null if not available" -- the word "Null" may have different meanings > to different people; some might interpret it as { '00'H } while others > might interpret it as { "" } (i.e. a string containing a single null > byte vs. an empty string). I'd suggest that the comment read > "Empty if > not available", if that is actually what is meant. I think this is unambiguous: It instructs the compiler to put a zero in the length field of ASN.1 encoding. We should have said 'empty' rather than 'null'. As you pointed out in a later note, "" would have been a better choice for a Display String, but this is now moot (this object was originally an OCTET STRING but we incorrectly changed it during work on the implementation) Mark From rem-conf Fri Apr 30 05:23:19 1999 From rem-conf-request@es.net Fri Apr 30 05:23:17 1999 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 10dCH1-0000iv-00; Fri, 30 Apr 1999 05:20:07 -0700 Received: from primus.ac.net ([205.138.54.1] helo=usa.net) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 10dCGz-0000il-00; Fri, 30 Apr 1999 05:20:05 -0700 From: Donations To: rem-conf@es.net Subject: They need Your help! Message-Id: Date: Fri, 30 Apr 1999 05:20:05 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Sir/Madam ! The Crisis in Kosovo is dramatically turning for the worse. Kosovar's Albanian's were subjected to ethnic cleansing and systematic expulsion from their territory and now more than 600 000 of the peaceful inhabitants are forced to search for shelters in the amicable countries. Many of them, first of all children and women, are starving and go through diseases, but humanitarian program of the countries of NATO can't help all requiring. If you sympathizing these deeply unhappy people, who are not guilty in the circumstances and if you have a possibility, please provide whatever support you are able. We appeal for aid to all who are not indifferent to the fate of unfortunate children. Please, help this people. They need your friendly hand, as never before! PLease, visit our site: http://Help-kosovo.com Any amount of financial aid (the account is written below) would help destitute people to survive. 71617 HELP Federal Bank of Middle East Cyprus off shore Banking Unit P.O.BOX 3498, 3303, Limassol, Cyprus God Bless you. From rem-conf Fri Apr 30 16:58:43 1999 From rem-conf-request@es.net Fri Apr 30 16:58:41 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 10dN5S-00028e-00; Fri, 30 Apr 1999 16:52:54 -0700 Received: from doggate.exchange.microsoft.com [131.107.88.55] by mail1.es.net with esmtp (Exim 1.81 #2) id 10dN5R-00028D-00; Fri, 30 Apr 1999 16:52:53 -0700 Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 30 Apr 1999 16:51:42 -0700 Message-ID: From: "Anders Klemets (Exchange)" To: 'Jonathan Rosenberg' , rem-conf@es.net Subject: RE: Usage of SDP with FEC Date: Fri, 30 Apr 1999 16:51:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > m=audio 44 RTP/AVP 0 34 > a=rtpmap:34 parityfec > c=IN IP4 123.3.4.5 > c=IN IP4 123.4.4.4 > a=fec:2 1 > > This indicates there are two unicast addresses. The FEC is protecting > the audio on the second port (123.4.4.4), and the FEC itself comes on > 123.3.4.5. The problem with the above example is that it may break clients that do not know about the "a=fec" attribute. Such clients will not know which unicast address carries the audio. The "fec" attribute establishes a mapping between the payload type and the unicast address, so without it, clients are left guessing. A similar problem happens when changing this example to work with RTSP. In RTSP, the port number will often be 0, and the IP address will be 0.0.0.0. With RTSP, the media description would look like this: m=audio 0 RTP/AVP 0 34 c=IN IP4 0.0.0.0 a=rtpmap:34 parityfec a=control:stream=A a=control:stream=B a=fec:2 1 Again, this breaks old clients, since they don't know if "stream=A" or "stream=B" applies to the audio stream. Even though the SDP spec may allow for multiple "c=" lines per media description, and multiple "a=control" lines as well, I suspect most current SDP implementations do not expect a media description to have more than one. Anders