Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.toronto.edu!ietf-nntp-distribution-owner Message-ID: <9106251328.AA15950@funet.fi> Original-To: Eliot Original-Cc: sob@tmc.edu (Stan Barber), ietf-nntp@turbo.bio.net Subject: Re: compression methods References: Your message of Mon, 24 Jun 91 21:25:57 -0700. Date: Tue, 25 Jun 1991 09:28:40 -0400 From: Harri.Salminen@funet.fi (Harri K Salminen) Newsgroups: list.ietf-nntp Distribution: list Sender: list-admin@cs.toronto.edu Approved: list.ietf-nntp@mail.cs.toronto.edu Lines: 30 Your message dated: Mon, 24 Jun 91 21:25:57 PDT > It saves money if you're unfortunate enough to have to pay usage > sensitive rates. My understanding is that this is the case for certain > transatlantic rates, and it places like Korea. Compression is also much desired for slow speed lines be they volume charged or not. Many Central European (former European except USSR) countries for example have 9.6 lines that they intend to multiplex with other traffic to get even a very slow IP connection. Also many IP links that go over 64K or lower speed X.25 networks could benefit from compression. Currently those places prefer batched uucp or NJE transfers because of scarce bandwidth. Enough for European problems, I think this should convince you that we need OPTIONS for several compression schemes that could be used link by link basis. > Against compression: > It adds overhead and it requires a name registry, and it adds a little > bit of hair into the implementations. If it's an option it could even be agreed bilaterally although names for few popular compression schemes could be defined in the RFC. Anyway it should be optional so that if you don't like you don't support it. > Comments? > Eliot Lear > [lear@turbo.bio.net] Harri