Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!orion.oac.uci.edu!ucivax!gateway From: JPALME@qz.qz.se (Jacob Palme QZ) Newsgroups: comp.protocols.iso.x400 Subject: Notes from the ISO/IEC/CCITT X.400 development group Message-ID: <525660*JPALME@QZ.qz.se> Date: 25 Nov 90 17:33:32 GMT Lines: 211 Approved: usenet@ICS.UCI.EDU Autoforwarded: true Notes from the ISO/IEC/CCITT X.400 development group ==================================================== Geneva, November 12-21, 1990. The collaborative meeting between CCITT Study Group VII/Question 18 and ISO/IEC JTC 1/SC 18/WG 4 Special Working Group on Messaging has just finished in Geneva. Here are my personal notes from the meeting, this is not the official minutes of the meeting. X.435 final (?) editing ----------------------- More than a hundred reports of bugs and deficiencies in X.435 (the standard for carrying EDI in X.400) were handled. A controversy on how the content type for EDI should be given in the P1 envelope was handled. The decision was to use only the integer 35, and not any object identifier. This makes things simpler, even if some fundamentalists may not like the decision. X.400/88 defect group --------------------- The X.400/88 defect group also handled a large number of defects in X.400. General enhancement group ------------------------- One major point of discussion in the General enhancement group was how to use X.400 for communication between multi-telefax senders. Example: A sender in Europe wants to send a fax to 10 U.S. recipients. He delivers the fax to a European multi-fax vendor, who puts the fax into an X.400 message sent to an American multi-fax vendor, who will then distribute the fax to its recipients. A controversial issue was how to handle delivery notifications for messages from X.400 to be delivered as fax. The present standard says that a delivery notification should be sent when the message is turned over from the X.400 MTS to the Access Unit (=Fax sender). An American contribution wanted to send delivery notifications instead when the fax had been successfully delivered to the recipient fax machine. The decision was that for the special case of store-and-forward fax service (described above) two notifications will be produced, one at delivery to the remote fax sender and one at the delivery to the recipient fax machine. The latter will probably look like a recipient notification and will be called "rendition notification". My proposal to allow conversion between P2 and P22, entered after discussion here in the MHS News mailing list, was rejected without reason. About two years ago, I sent in a proposal to add to the IPM heading an "auto-submitted" indication when a message had been automatically generated by a machine has gone through a curious history. At two previous meetings, the enhancement group had decided that this should go into the P1 envelope, not into the IPM heading. But now, they had changed their mind again, and moved it back to the IPM heading as I originally proposed. A proposal was accepted to help accounting in P1 by indicating in a simple way in the envelope if a message is any of several different kinds of notifications (which maybe should be billed on the recipient of the notification) was accepted. This proposal can be implemented also in 1984 X.400 systems. Another topic in the general enhancement group was file transfer in MHS. The group has decided to suspend development of file transfer as a separate content type, and concentrate work on file transfer as an IPM body type. This body type will, in addition to the file itself, contain certain parameters on the file taken from FTAM. These parameters are: - filename - permitted actions - contents type - date and time of creation - date and time of last modification - date and time of last read access - identity of creator - identity of last modifier - identity of last reader - filesize - future filesize - legal qualifications - private use The following issues are not yet resolved for file transfer in MHS: - How detailed should the contents type be (e.g. binary file, spreadsheet or Lotus 1-2-3 ver. 5.0). - Is there a requirement for multiple File Transfer body parts? - Are the security elements-of-service currently defined in X.400 sufficient for file transfer? The Message Store enhancement subgroup -------------------------------------- This group has been a very controversial group, because the British delegation very strongly favours a lot of enhancements to the Message Store, in order to make it useful for long-term storage of messages. Among the many ideas are folders and automatic filters to sort incoming messages into different folders according to their attributes. This proposal has been opposed by most other countries. Their main reason is that they do not want to extend a new standard so much and so soon, since this may stop implementors from implementing it. Also, they feel that the MS should not be extended to become a competitor to DFR (Document Filing and Retrieval), in order to avoid having more than one standard for similar purposes. The following extensions to MS have been accepted: - Storage on submission. - Stored message tagging. - Stored message auto-modification. - Storage of draft messages. - Stored message lapsed time. - IPM-stored message purging. - Inlog and Outlog. - Auto-correlation of reports. - Auto-correlation in IPM. - Auto-correlation in Pedi. The following extensions are not accepted: - Stored message timed alert. - Submission of stored messages. - Forwarding history. - IPM auto-obsoletion. No decision could be taken on extending the MS with "Non- repudiation of retrieval" since no security experts participated in the meeting. A rather sharply worded liaison letter was sent to the Directory Group, because this group had changed the filter definition (which is used also in the message store) without liaison with the MHS group. Visual representation of O/R addresses -------------------------------------- The group on this have now agreed on a modification of the RARE format for writing O/R addresses on business cards etc. This will probably soon be sent out for balloting to ISO member bodies, probably in February 1991, immediately after the meeting with the X.400 development group there. The standard will propose to formats for O/R-names. One short format, which may e.g. look like this: X.400: G=nigel; S=bevan; O=ucl; P=uk.ac; A=gold 400; C=gb and one longer format which is language dependent and may look like this: Country (C): GB ADMD: Gold 400 PRMD: UK.AC Organisation (O): UCL Org. Unit (OU): ESS Surname (S): Bevan Given name (G): Nigel The text outside the parenthesis will vary with language, the abbreviation in parenthesis will always be as given above. Two issues are yet unresolved: (a) Should the delimiter between fields on a single line be ";" or "/". (b) In which order should the elements of the name be given. One of the following orders will be used: G S O P A C (advantage: More like postal addresses, with the smallest unit first). C A P O S G (advantage: No problem with ordering of OU-s). Group communication group ------------------------- I will report in a separate message from this group, in which I myself participated. Other groups ------------ Work was also done in a group on MHS Management and routing, and a group on voice messaging. Future meetings of the X.400 development group ---------------------------------------------- 13-22.2.91 in Wollongong, Australia. 19-28.6.91 in Ottawa, Canada 16-25.10.91 somewhere in Europe. An interim group may meet, if needed, in February 1992.