JPALME@qz.qz.se (Jacob Palme QZ) (03/13/91)
X.400 development group notes ============================= The joint ISO/IEC (JTC 1/SC 18/WG 4), CCITT (Study Group VII, Question 18) group and CCITT (Study Group I, question 15) for further development of the X.400/MOTIS standard for electronic mail met in Wollongong, Australia, February 13-22, 1991. These are my personal notes from the meeting, no official minutes. Gulf War impact --------------- Because of the Gulf War, all U.S. and Japanese representatives, and a few others, did not come to the meeting. (Why a war in the Middle East should stop people going to a meeting in Australia is something I do not understand!) Because of this, only 27 delegates came, about half as many as normally. There had been discussion, before the meeting, of cancelling the whole meeting. ITU, however, had said that CCITT meetings should not be cancelled because of the war. Criticality ----------- X.400/1988 contains a feature called criticality. By this is meant that a message envelope may contain new envelope attributes, which are not part of the 1988 version of the standard. Criticality then determines how an MTA which does not understand such a new envelope attribute should handle it. If the new attribute is marked as critical, the MTA should reject the message (usually returning a non-delivery notification). If the attribute is marked as non-critical, the MTA should accept the message even though it contains an attribute it cannot understand. The idea with this feature is to enable old implementations to handle messages with new features in a more intelligent manner. This is also called "controlled transparency". The reality is even more complex, since X.400/88 allows a new attribute to be marked as critical for submission, critical for transfer and critical for delivery. An MTA which just transfers a message between two MTA-s, would then for example accept a message even though the message has a new attribute which is marked as critical only for delivery. All this has been in X.400 for many years. What was discussed at the Wollongong meeting was certain special cases of this. (1) Should an MTA which receives a message with a new parameter marked as non-critical for submission still be allowed to reject the message if the sender for example has not paid an additional subscription fee for use of the new parameter? Answer: Yes! (2) Should a message which goes between two UA-s at the same MTA, and thus is never transferred between MTA-s, still be rejected if it has a new feature which the MTA does not understand and which is marked critical for transfer? Answer: Yes! (3) How should per-recipient critically marked extensions be handled? Answer: Reject only for recipients with the responsibility flag on, and if critical for delivery, only when delivering to the recipient with the critical attribute, and accept delivery to other recipients. Fax recipients -------------- At present, X.400 does not do enough to specify which is the final recipient of a fax message sent to a fax machine used by many users. It was proposed to handle this by extensions to the Terminal Form O/R address with some additional attributes. Notifications when sending from X.400 to Fax -------------------------------------------- There was a discussion on whether a delivery notification should be sent, for a message which is transferred from X.400 to facsimile, either: (a) At the delivery to the so-called access unit, i.e. from X.400 to the Telefacsimile transfer system. (b) At the delivery to the recipient fax machine. We decided on (b). However, future work may include adding new variants of delivery notifications, including notifications sent at delivery from X.400 to a fax transfer system. We also decided that receipt notification are not meaningful when delivering from X.400 to fax. Multi-national ADMD-s --------------------- There was a discussion on whether to extend X.400 to allow multi-national (also called supra-national) ADMD- s. This could be done, for example by adding a new country code, e.g. "UN" for United Nations, and allow ADMD-s to register under this new country code. Examples of organizations which might want to do this would be multi-national companies (e.g. Shell Petroleum) or multi-national electronic mail service vendors (e.g. IBM and GEC). Result: No final decision was taken, but the general opinions in the meeting seemed to be that registration of multi-national MD-s will not be accepted. Instead, an ADMD or PRMD which wants to work in more than one country should register itself in each country separately. This may mean that the same recipient may sometimes be represented by more than one O/R-address. Thus, alias O/R-names will occur. This will cause undesirable consequences. To limit these, the same O/R- address should be used as much as possible, and a different address only used when necessary to achieve the desired routing. One might expect that ISO delegates would have wanted to allows multi-national MD-s, but no such proposal was made by the ISO delegates present at this meeting. Route for returning notifications --------------------------------- For accounting reasons, notifications should be returned via the reverse route through which the message, to which they pertain, was sent. Accounting management --------------------- A first draft of how MHS accounting can be managed was developed in document MH-509. The draft describes how to produce MHS accounting logs, when logs are to be produced, and will also when ready describe how accounting information can be transported between MD-s. Character set issues -------------------- The use of Printable Strings in O/R-addresses will gradually be phased out. Probably it will be replaced by T.61 strings, as specified in the 1988 version of X.400, but some people claimed that T.61 did not meet the requirement. Mandatory support of T.61 to IA5 conversion will probably be required in the future, in order to ease the gradual change from IA5 to T.61 as the main text format in X.400. Extensions of IP-notifications ------------------------------ An extension mechanism for IP-notifications will be developed. Compression ----------- Extending X.400 with standards for the compression was thought valuable. Preferably, this should be done by compression of body parts, since a compression scheme knowing the type of the text might be more efficient, and also sine fax already has compression, and double compression can sometimes be harmful. Contributions on how to add compression to various body parts were requested. Another possibility might be compression at a lower network layer. Compression of contents was not considered appropriate. General text ------------ The ISO version of X.400, MOTIS, has a body part type called "General Text" which can be used to transfer a text in any character set registered with ISO, for example ISO 8859 (often called "Eight Bit Ascii"). This new body part type could then be used, instead of having to define a new body part type for each character set. We now got a complaint that the General Text body part was defined in such a way, that it does not allow switching between different character sets within the text using ISO 2022 Escape Sequences. (In cases where the Escape Sequences caused changing of the g0, g1, g2, g3, c0 or c1 character set boxes, as defined in ISO 2022.) Because of this, conversion from the Teletex (=T.61) body part type to the General Text body part type would not always be possible, since the Teletex body part type allows such switches. We decided to change the ASN.1 for the General Text body part type, to allow such switches. Security logs ------------- A first version of a document describing security logs and audit trail in message handling was developed, document MH-518. Message store enhancements -------------------------- A very controversial issue has been enhancement of the message store with various new features, including folders and automatic handling of certain incoming messages, e.g. sorting them into different folders depending on their attributes. Folders will be provided, but folders will be called "groups" instead of folders. Other extensions are storing of submitted messages in the message store (presently only received messages are stored), a life-time attribute on messages, saving of half-finished messages in the Message Store for later use, attachement of personal notes to messages, cooperation with document stores in how the actual documents within messages are stored. File transfer in MHS -------------------- The group has been working with the development of file transfer facility in MHS, that is to allow messages to contain files (e.g. binary files, spreadsheets etc.). The group had earlier concluded that file transfer was to be implemented with one or more new body part types. These body part types would describe files in similar ways to the way FTAM describes files. We now had two written input on this: (1) The group responsible for FTAM wanted us to refer to the file descriptions in FTAM instead of developing our own file descriptions, similar to FTAM. We replied that we are so closely aligned to FTAM; that they ought to be happy with our work. (2) SWIFT wanted us to allow file transfer in new content types instead of new body types. The reasons for this desire from Swift was that this could give better security services for file transfer. No decision was reached on this. Contributions are requested. Work will continue on developing file transfer in body parts, and to make this as FTAM compatible as possible. Distinguished Object Reference ------------------------------ ISO/IEC JTC 1/SC 18/WG 4 Special Working Group on Distributed Office Architecture has developed a new standard called Distinguished Object Reference. This standard can be used in cases where you would normally send a document. Instead of the document itself, you would send only a reference to the document. Examples of use would be when a workstations sends a file, which is stored in a remote store, to a printer. Instead of first copying the file into the workstation, and then copying it again from the workstation to the printer, the workstation could just send a reference to the document to the printer, and the printer could then use this reference to retrieve the document from the remote store. This could save a lot of time, especially in cases where transfers to and from the workstation are slower than transfer to and from the remote store and the printer. The question now was whether this could be used in X.400, for example in the Message Store when a user wants to print a message from the Message Store. Result: No decision at the present meeting, since no specific solution was proposed in the input paper. If a detailed technical solution is presented as input to the next meeting, this will be considered. Object Reference Harmonization ------------------------------ A related topic was that SC 18 was conducting a new work item ballot on a new work item called Object Reference Harmonization. The background to this is that many different standards allow different ways of referring to (uniquely identifying) documents (for example the IPMessageID in X.400, The Distinguished Object Reference in DOA etc.) These references can only refer to other documents within the same standard. For example, an X.400 message can refer to another X.400 message using the IPMessageID, but it cannot refer to an ODA document. The idea is now to try to define a general object referencing mechanism, which can be used by all different standards, to allow references from a document in one standard to another document in another standard. This is something I have wanted to have for many years, so I am very happy that the idea is now getting more general support. The idea has come up in SC 18, and we decided to write to them expressing our support for this new work item. Representation of O/R-addresses for human exchange -------------------------------------------------- Further work was done on this. It is now accepted that only semicolon (;) or new line in tables, and not slash (/) shall be used between attributes in the representation. The fields will be given with the innermost value (Given name) first, and the outermost value (country) last, except that Organizational Units are listed in the reverse order from this. User Interfaces should to some extent be suitable for this format, in the order in which attributes are handled and in the abbreviated names given to the attributes in the user interface. Group communication ------------------- The group communication subgroup has specified a general information model for group communication and an abstract service definition for computer conferencing. The work on mapping computer conferencing on the general information model is not yet finished. Future work includes finishing this mapping, further work on the distributed architecture and development of ASN.1 and protocols. Not yet clarified issues are whether to only use the master-shadow technique for updating, whether to represent links as separate link objects or not, how to name contributions. A main issue in the group communication group is still whether to produce a special protocol for computer conferencing, or only produce a general protocol for group communication and map computer conferencing on the general protocol. Another main issue is how to obtain downwards compati- bility with X.400 (88). This might be possible by using some clever, but possibly unintuitive, coding of group communication contents transported via MTS. Murray Turoff help us with Group Communication? ---------------------------------------------- We heard rumours that the U.S. intended to send Murray Turoff, the man who invented computer conferencing, as a representative to future Study Group I/Question 15 meetings. This is a very happy rumour, if it is true. I have for several years tried to persuade Turoff to participate in this work. There may be some difficulties however, if Turoff comes in as a new participant so late in the work. Will he want to redo everything we have done before he starts to participate? From: Jacob Palme <jpalme@QZ.SE>
hsilbiger@attmail.att.COM (Herman R Silbiger) (03/20/91)
In article <605950*@MHS>, JPALME@qz.qz.se (Jacob Palme QZ) writes: > X.400 development group notes > ============================= > > The joint ISO/IEC (JTC 1/SC 18/WG 4), CCITT (Study Group > VII, Question 18) group and CCITT (Study Group I, > question 15) for further development of the X.400/MOTIS > standard for electronic mail met in Wollongong, > Australia, February 13-22, 1991. > > These are my personal notes from the meeting, no > official minutes. > > Gulf War impact > --------------- > > Because of the Gulf War, all U.S. and Japanese > representatives, and a few others, did not come to the > meeting. (Why a war in the Middle East should stop > people going to a meeting in Australia is something I do > not understand!) > > Because of this, only 27 delegates came, about half as > many as normally. > > There had been discussion, before the meeting, of > cancelling the whole meeting. ITU, however, had said > that CCITT meetings should not be cancelled because of > the war. > While I agree that there may not have been any real risk in attending a meeting in Australia, I do not believe that the reason for not canceling the meeting was the ITU statement that CCITT meetings should not be canceled. This statemtnapplies to CCITT meetings. Technically, Rapporteur Group meetings are not CCITT meetings. No meeting below the level of a Working Party is considered an official CCITT meeting, and any activity or agreements reached at such meetings have no standing unless approved by the applicable Working Party or Study Group. Because Rapporteur's meetings are not "official", individuals who are not CCITT members could be invited to participate. This is not possible at official meetings. By the way, the joint Q27/VIII-JTC1/SC18/WG3 meeting scheduled for Melbourne, Australia 4-15 February 1991 was canceled, since only 9 out of 34+ members indicated they would come. Herman Silbiger SpR Q.27/VIII Chair, Working Party 4, CCITT Study Group VIII.