draskoy@ubc-ean.UUCP (Andrew Draskoy) (10/27/86)
> I'm told that X.400 separates its address and data as well. > [...] > Speaking of X.400 doesn't that use some magic internal format which > means that you really need either conversion programs in and out or a > complete new subsystem, including editors and such? > -- > Jonathan Clark > [NAC,attmail]!mtune!jhc X.400 uses a binary data format which is language independant (in terms of header and envelope, not data). The envelope, header, and body are seperate. The body may be composed of many parts, each of which can be ASCII, telex, FAX, videotex, voice, etc. The binary data format uses X.409 which is essentially a way of turning linked data structures with sets, sequences, etc. into a byte stream. X.400 defines everything you need to get from one user agent (UA) to another. The inner workings of the UA are not defined, however, so you can store things any way you like (though X.409 is convenient, of course). It is a pain to have things in binary if you just want to look at a message or run it through some UNIX filters, but it is great for working with inside a program, since X.409 can be converted straight into a linked data representation, and of course you don't need to parse it every time you want to do anything. > Perhaps we should all convert. To something. The trend internationally is definately towards X.400. Within the states ARPA and hence RFC822 still have a very strong hold, so X.400 is being resisted. When people do convert from RFC822, it seems that X.400 would be the logical choice. Certainly most of the public messaging systems are planning X.400 compatability or gateways. I've been thinking of writing a series of short summaries of the various bits of X.400 if anyone is interested, since I keep getting questions about it, and this may save me time in the long run. Send me a message if you would like to see this. Andrew Draskoy draskoy@ean.ubc.cdn