Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!ucivax!gateway
From: Christian.Huitema@mirsa.inria.fr (Christian Huitema)
Newsgroups: comp.protocols.iso.x400
Subject: Re: DATA Compression and X400 standards
Message-ID: <9011050850.AA12186@jerry.inria.fr>
Date: 5 Nov 90 08:51:09 GMT
Lines: 26
Approved: usenet@ICS.UCI.EDU
In-Reply-To: Your message of 30 Oct 90 23:16:57 +0100.
             <1990Oct30.162942.11200@bnrgate.bnr.ca> <12383.657313449@ics.uci.edu> <657322133.20613.0@aun.uninett.no>

Peter,

I agree with your general remark that compression could be done at the
presentation layer. In fact, we at INRIA played with presentation layer
compression for two years, and came to the conclusion that defining a
presentation transfer syntax as e.g. the stacking of a LZ or Hamming coding over
BER (or faster) coding rules is both feasible and useful. There are a couple of
problems to solve, essentially relating to the limited negociation capabilities
of the presentation protocol (how do you negociate the size of the LZ
dictionnary?) and also to the "tree" structure of the encoding (how do you handle
an EXTERNAL quoted within a compressed syntax?). The case of X.400 is much
harder to solve, however:

* The bulk of the data is within the "content", which is carried as an "octet
string".

* The exchange of messages between UA is "connectionless".

Using the presentation layer compression for X.400 would be done within a single
context, that of the envelope. Not very interesting... And the octet string
"content" is only typed by a "content identifier", pointing in principle to some
ASN.1 content description, e.g. P2. There is no place to indicate that something
else than ASN.1 BER was used for the encoding -- and the same is true for the use
of the EXTERNAL construct in the absence of presentation negociation.

Christian Huitema