lear@turbo.bio.net (Eliot) (06/25/91)
With regard to the COMPRESSION option, I'd rather that the compression method be negotiated such that prearrangement need not be necessary in all cases. Unfortunately, yes, this would also require a name registry. If a compression is used that is not in the registry, then it must be prearranged. Comments? Eliot Lear [lear@turbo.bio.net]
sob@tmc.edu (Stan Barber) (06/25/91)
Why build compression in? Why not just use the same mechanism uucp/batching uses now? Adding compression adds ALOT of overhead. Using image/binary and the existing news batching adds very little. If the goal it to make low speed lines usable (say over a NetBlazer) with NNTP for TRANSMISSION (not READING), compression in nntp is not necessary. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
lear@turbo.bio.net (Eliot) (06/25/91)
Let me take up both sides of this issue. For Compression: 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 might be only a variant of IMAGE for some implementations if they store articles in compressed form (TMNN comes to mind; does CNEWS allow articles to live on the disk in compressed form?). Against compression: It adds overhead and it requires a name registry, and it adds a little bit of hair into the implementations. Comments? Eliot Lear [lear@turbo.bio.net]
Harri.Salminen@funet.fi (Harri K Salminen) (06/25/91)
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
mcb@presto.ig.com (Michael C. Berch) (06/25/91)
[Eliot writes:] > With regard to the COMPRESSION option, I'd rather that the compression > method be negotiated such that prearrangement need not be necessary in > all cases. Unfortunately, yes, this would also require a name > registry. If a compression is used that is not in the registry, then > it must be prearranged. > > Comments? Ideally, I think it would be best if we could eliminate all requirements for name registration. This question has come up with respect to authentication and/or encryption scheme names, as well. Since it seems to be accepted that in the present model NNTP connections exist only by prearrangment, then I do not think it is too much to ask that "nonstandard"[1] feed parameters be prearranged also. Presumably NNTP implementations will make reference to certain well-known compression or authentication schemes, and these names will form the basis for mutual pre-arrangement. To try to do more commits the community to yet another cumbersome name registration scheme. -- Michael C. Berch mcb@presto.ig.com [1] A "standard" feed would be the present common modality, i.e., a feed of by an active transmission client without compression, batching, authentication, encryption, or state information other than IHAVE.