dcrocker@TWG.COM (Dave Crocker) (07/18/88)
It has been interesting to watch the discussions about the specification of handling information, such as non-delivery notification. This was a point of particular concern, during the development of the MCI Mail system. The basic conclusion was that per-addressee, vs. per-message, clearly provided the best flexibility. However, the burden placed on users can get quite painful, so that a per-message approach to user-level specification was chosen. The theory was that contingent assignment of different values was relatively rare. (Keep in mind that the user interface model was 1200 baud, simple ascii text.) Given a graphics- and forms-oriented interface, the choices could be different. With respect to coding such information into RFC822 format, you can live within the current standard and develop a downward compatible spec or you can develop a specification that will break some other systems. Anything within parentheses is completely save, according to the spec, although many systems interpret such "comments" as personal names. Anything in local-part is safe, except for the delivery system on the host that interprets local-part. In either case, any information put in either place, when a message is sent, is likely to show up in a reply message. What happens when you reply to the reply? Unless you get cooperation from all of the end-points and the gateways, you will propagate handling information in ways that is likely to be undesireable. An alternate approach is to upgrade 822 and choose another port for mail transfer. This lets participating hosts talk with each other, without requiring participation from all hosts. You are then left almost only with a problem of choosing specification syntax, a relatively minor task. Dave
taylor@cs.glasgow.ac.UK (Jem Taylor) (07/26/88)
In article <8807201652.AA16735@tis.llnl.gov>, dcrocker@TWG.COM (Dave Crocker) writes: > An alternate approach is to upgrade 822 and choose another port for > mail transfer. This lets participating hosts talk with each other, without > requiring participation from all hosts. You are then left almost only > with a problem of choosing specification syntax, a relatively minor task. "using another port for mail transfer" presumably refers to the SMTP protocol port used over TCP on the Internet to transfer RFC822 messages. RFC822 messages are also moved using JNT Greybook mail over NIFTP on JANET; using UUCP over various media on various networks; etc. and in article <1611*erik@sydney.cdn>, erik%sydney.CDN@ean.ubc.ca (Erik Skovgaard) writes: | I would tend to agree with Dave. Given the number of users of RFC-822-based | mail systems, it is likely that "temporary" is for a long time. | | I disagree with Jem that is is as easy to convert to X.400 as it is to | modify RFC-822. After all, we are only talking about a small change | here. Let me remind you that X.400 will change a lot more every four | years! and both have missed my point. Changing RFC822 may allow you to point the finger at virtually anyone who is currently running a system which doesnt conform to your proposed change, but does not address the problem at hand. My point is that, if system managers and maintainers have the resources needed to update their (current) RFC822-compliant system to your (changed) RFC822' standard, they have the resources to change to X.400 and should do the latter as they will gain much more. ( If you are willing now to change RFC822 for gatewaying reasons, might you not change it again throughout the life of X.400 as you track its changes ?! ) The motivation of the gatewaying project should be to allow the X.400 community to communicate (for extended periods perhaps) with systems which have not yet or never will be upgraded at all - many of which are now running systems which are only barely RFC822 compliant. Getting current systems up to the current RFC822 standard was not trivial; moving to X.400 will not be; adding a change to RFC822 is an unnecessary complication ! -Jem Taylor -- ARPANet:taylor@cs.glasgow.ac.uk | Mail: J.A.Taylor, Computing Science, JANET: taylor@uk.ac.glasgow.cs | Glasgow University, UseNet: mcvax!cs.glasgow.ac.uk!taylor | GB-GLASGOW G12 8QQ