Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!usc!orion.oac.uci.edu!ucivax!gateway From: anand@ka (Govindaraj Padmanaban) Newsgroups: comp.protocols.iso.x400 Subject: Re: DATA Compression and X400 standards Summary: MTA or UA?. Who can do the efficient compression?. Message-ID: <2279@excelan.COM> Date: 1 Nov 90 22:00:13 GMT References: <1990Oct30.162942.11200@bnrgate.bnr.ca> Organization: Novell, San Jose CA. Lines: 114 Approved: usenet@ICS.UCI.EDU x-attn: ah X-Previously-To: comp-protocols-iso-x400@ames.arc.nasa.GOV ReSent-To: mhsnews@ICS.UCI.EDU One thing which everyone is agreed upon is that "Data Compression" is really useful. (I hope so.) In that case, the next question is "Who can do the compression?". Which is the best place to put in?. If the burden is put on the MTA, every MTA on the route has to parse the message to get the body-parts to do the uncompress/compress. The message format received by the MTA looks something like this. P1 envelope +---------------------------------+\ | UMPDUEnvelope (P1 envelope) | \ | /* | \ | * This is the only part each | MTA can use and modify | * MTA has to parse and change.| only this portion | */ | / | Origin, ContentType, Recipients| / | Trace Information etc... | / +---------------------------------+ P2 message | UMPDUContent (P2 message) | \ | +-----------------------------+ | \ | | IM-UAPDU | | \ | | | | | | | +--------------------------+ | | | | | Heading | | | | | | IPmsgid, originator | | | | | +--------------------------+ | | | | | Body Part 1 | | | | | | | | | | | +--------------------------+ | UA formats this part | | | Body Part 2 | | and submits to the MTA | | | | | for sending. Only UA or | | +--------------------------+ | the Gateway MTA parses it. | | | o | | | | | | o | | | | | | o | | | | | | o | | | | | | | | | | | +--------------------------+ | | | | | Body Part n | | | | | | | | / | +--+--------------------------+ | / +---------------------------------+/ The relaying MTA is NOT suppose to do burden of compression/uncompression because it is not suppose to MODIFY the p2 message. Only the UA knows about the body-part boundaries. Each of the bodypart can be of different type (say text, exe, GIF image etc). A single compression algorithm may not work for all the body parts. Each body part has to carry the information about the algorithm used to compress also. Compression can't be handled by the lower layers. In the article, pww@uunet.uu.NET (Peter Whittaker) writes, >3) Compression is an example of manipulation of user data: from the OSI > purists perspective (I'm a purist on odd-numbered days - Happy Hallowe'en) > the last (lowest numbered) layer to touch user data is the presentation > layer (layer 6). Once it gets further down, the OSI stack assumes it's > safe to ship. > But how does the other side of the connection know > data is compressed? It seems to me that compression vs non-compression > would be part of the context negotiations at session establishment: > the iniatiator and responder would have to agree on what set of compression > routines to use, if any, and how to indicate to one another that compression > had been applied. It calls for all the type compression algorithm used by the bodyparts should be known before hand to negotiate the connection. I disagree with that. And also needs a basic change in the message format to carry the compression information. And with the single negotiated connection you can't transfer all the messages to the next MTA. And for every message you can't negotiate the connection also... Route 1 origin UA ==> MTA-10 ==>MTA-11 ==> ..... ==> MTA-1N ==> UA (recipient) | | | | | route 2 | MTA-20 ==>MTA-21 ==> ..... ==> MTA-2M If one MTA doesn't know of the compress method used in the message, the routing decisions are affected to transfer the message. I hate when this happens. I really vote for the Sending and Receiving UAs to do the compression. It calls for a little bit of intelligence on the UA part. It also makes sense. The message originator knows about the types of body-parts and the compresss algorithm used. The receiving UA has to do the uncompress operation. The job of MTA is to transfer the message rather than changing/modifying it on the fly. If the receiving UA can handle the new compress method, all the MTAs in the route need not change at all. Any suggestions welcome. Anand +------------------------------------------------------------------------+ | We have not inherited the earth from our parents, | | but borrowed it from our children. | | Govindaraj A Padmanaban - Novell Inc. 408-473-8643(w) 408-263-7055(h) | | Email: anand@novell.COM {ames | apple | mtxinu | leadsv }!excelan!anand| +------------------------------------------------------------------------+ +------------------------------------------------------------------------+ | We have not inherited the earth from our parents, | | but borrowed it from our children. | | Govindaraj A Padmanaban - Novell Inc. 408-473-8643(w) 408-263-7055(h) | | Email: anand@novell.COM {ames | apple | mtxinu | leadsv }!excelan!anand| +------------------------------------------------------------------------+