karl@asylum.sf.ca.us (Karl Auerbach) (12/16/89)
"Real-time" really was the wrong word. I ought to have said something like "in electronic mail, total throughput is often not seriously affected if it takes a bit of work to parse a message and its body, but for remote operations, association control, file transfer, ... the overhead of examining virtually every byte can become an unacceptable overhead and, because of the resultant response delays, total system throughput may be greatly reduced." One needs to parse e-mail only when a user (or program acting as a user reads it). Header parsing of mail for routing is also a fairly infrequent event. (Infrequent is a relative term. For purposes of context, I consider PDU arrival/transmission to be "frequent".) In my first X.400 implementation, I parsed incoming packets only as needed (usually when they arrived and had to be delivered to some user). All internal activity (reading and composition) was done using an internal data structure. Basically, what this boils down to is that ASN.1 parsing of e-mail only need occur once for each incoming or outgoing message (which I claim is "infrequent") and need not occur at lightning rates because it is essentially governed by human, not computer, timescales. (My argument falls apart if e-mail is used as a form of program-to-program transfer.) On the other hand, remote operations (to pick one example) can occur with great frequency and the ASN.1 processing had better happen "right now" else the system becomes unresponsive. With regard to your question why I think ASN.1 (actually x.409) makes sense for multi-media documents: It is a very efficient way to hold things of arbitrary structure and format which may be nested one within another. (I don't want to be on record supporting some of the oddball parts of X.409, however, such as its insistance of squashing integers, weird encoding of tag and length fields, the distinction between implicit and explicit tagging, not-quite-macros, ...) --karl--