JPALME@QZCOM.BITNET (11/11/88)
>X-Bitnet-Sender: "Jacob Palme QZ" <JPALME@QZCOM.BITNET> Report from the meeting with ISO/IEC JTC 1/SC 18/WG 4 in Los Angeles, September 1988. File transport standards ------------------------ There are several standards, ready or under development, which can be used to transport files across data networks: FTAM: File Transfer Access and Management. Developed by SC 21. DTAM: Document Transfer and Manipulation. Developed by CCITT Study Group VIII. Specially designed for the transfer of videotex text and ODA documents. Contains ODA, and is the tool for making ODA into a CCITT recommendation.(ODA = Office Document Architecture, a standard for the exchange of word processor documents.) DFR: Document filing and retrieval. Developed by SC 18/WG 4. DFR describes a hierarchically structured document store, and operations on it (entering and fetching documents etc.). DFR differes from FTAM in that it does not look into the internal of documents, you can only transport whole documents, while FTAM allows you to access individual records of a file. Because of this, DFR does not require any knowledge of the internal structure of the document. DFR has a more complex organization of the document store, with folders and folders within folders, of the kind common in office systems. It also allows one and the same document to occur logically at several places in the tree structure. RDT - Referenced Data Transfer. Developed by SC 18, this is a way of transporting references to documents, without having to transport the whole document, which is useful in many cases (for example when the sender and recipient have equally good access to the FRS where the document really resides). DOAM: Distributed Office Architecture and Management. Developed by SC 18, this is a general structure for handling an office environment with components from different manufacturers (like document stores, printers, user agents, mail sorters etc.) so that the components can interwork. DOAM uses a standardized way called ROSE, for the different components to talk to each other. DFR, RDT, MOTIS (X.400) are examples of services within DOAM. Now to the problem: There is a controversy between SC 21 and SC 18 because both have developed standards which can be used for file transfer, FTAM and DFR/RDT. Some SC 21 people feel that it is not good to have two different standards for doing the same thing. SC 18/WG 4 feels that FTAM does not satisfy the needs in the office environment, and that if SC 18/WG 4 has to wait until FTAM gets these facilities work in SC 18 on the distributed office will have to wait many years. Also, FTAM does not use ROSE which is the standard way in which SC 18 wants to handle all communication between components in the distributed office. Here are some facilities of FRS which are not available in FTAM: > Management of the file store, moving and copying files. > User-defined attributes on files. > Searches for files based on attributes on them. Management of search results. > A reference mechanism to store the same file logically in several places without actually copying it. > Handling different versions of a file. > Handling references to documents, where the document text itself is not available in machine-readable format. Facilities available in FTAM but not in DFR are: > Knowledge of the internal structure within a file. > Ability to retrieve or modify individual records within a file. Here are some advantages of using ROSE for handling remote operations: > Different applications can use the same ROSE-module for handling the communication, this saves considerable development costs. > It is easy to add new extensions using ROSE. > A concise and well-defined discipline for specifiying remote operations. > Defined mappings exists both for local and wide-area networks. This controversy has caused much problem in SC 18/WG 4. People in that group feel that they will not be able to continue doing work on the distributed office, if SC 21 tries to stop them by declaring their work to in conflict with what SC 21 does, but when at the same time SC 21 does not have alternatives satisfying the needs of SC 18. The latest action in this "war" between SC 21 and SC 18 is that SC 21 has called for a "workshop on upper-layer applications", with a program intended to favour the SC 21 view, and (according to WG4 people) intentionally choosing a date for this workshop where few SC 18/WG 4 people can attend because of a functional standards meeting at the same time. Almost a whole years work has been lost in SC 18/WG 4 on this problem, and now SC 18/WG 4 is not willing to delay its work any more, work on DFR must go forward. This problem was discussed and the solution seems to be that SC 21 is going to accept that SC 18 continues work on DFR, but that the SC 21 group working on FTAM and the SC 18/WG 4 should cooperate in order to make DFR and FTAM similar where possible. In particular, the organization of the file store should, if possible, be such that both DFR and FTAM can be used to access the same file store. Security in DOAM ---------------- We have had complaints that DOAM (Distributed Office Architecture and Management) does not cater enough for security and will have to clarify how security is going to be handled in it. Report from the CCITT EDI group ------------------------------- The CCITT has had a meeting with an interim group on how to incorporate EDI (Electronic Data Interchage) in X.400. This is regarded as a very important item just now, and there were about 60 people at the meeting, about one third EDI expertsand two thirds X.400 experts. The group hopes to have a CCITT recommendation ready for acceptance already in 1990. Some problems: > EDI messages can be several hundred megabytes. Functional standards for X.400/MOTIS only require the capability of handling messages up to one megabyte. > EDI will be a separate content type in MOTIS. > EDI people have a different global naming scheme and a different abstract syntax notation than X.400. They do not wish to use MOTIS-specific things, because they want to be able to use either MOTIS or FTAM or TELETEX to transport EDI information. > They want to use the Message Store facility of X.400, and thus use the 1988 version of X.400. Future WG4 work --------------- Future meetings with ISO/IEC JTC 1/SC 18/WG 4 will be one-and-a- half week in duration, starting on a Monday, ending on a Wednesday. RDT - Referenced Data Transfer ------------------------------ There was a long heated discussion on whether RDT should be seen only as a tool within DOAM for handling communication between agents having access to a common store, or should be seen as a major application in its own right, needing a new work item, balloting to the ISO member bodies before studies begin etc. Subgroups --------- We then split up into the following subgroups: (1) Group on Document Filing and Retrieval (4 persons). (2) Group on Distributed Office Architecutre, incuding planning for the workshop on distributed applications (10 persons). (3) Group on MOTIS/X.400, including Group Communication and EDI (8 persons). (4) Group on Printing Services (4 persons). ---------------------------------------------------------------- Title: Use of the DFR (Document Filing and Retrieval system) for group communication purposes. Status: Notes from discussions during the ISO/IEC JTC 1/SC 18/WG 4 meeting in Los Angeles, September 1988. ---------------------------------------------------------------- According to DFR specialists at the ISO/IEC JTC 1/SC 18/WG 4 meeting in Los Angeles in September 1988, most of the requirements from group communication (computer conferencing) can be satisfied by the DFR. The following model was assumed: +------+ +------+ +------+ +-----+ ! User !<--->! GCUA !<--->! GCSA ! <--->! DFR ! +------+ +------+ +------+ +-----+ GCUA = Group Communication User Agent GCSA = Group Communication System Agent Some user requests can be satisfied directly by the DFR. For other user requests, the GCSA may have to make several successive operations on the DFR in order to get the information needed by the user. This would for example probably be the case for a user who requested retrieval of all messages in a "conversation", that is all messages directly or indirectly related by InReplyTo- links. One such user request to the GCSA would result in several retrieval operations from the GCSA on the DFR, following one level of InReplyTo-links at a time, until the full conversation has been found. Hierarchical structures of conferences are possible to represent in the DFR using the GROUP concept. Relations between messages in a conversation can be handled in several ways: (1) Using the GROUP concept of DFR. (2) Using the VERSION management facility of DFR. (3) Using the USER REFERENCE facility of DFR, this allows an attribute of one object to refer to one or more other objects. (4) Using the DFR REFERENCE facility. Probably the most suitable way is to use the USER REFERENCE facility. There is some question on whether attribute handling in DFR is satisfactory for Group Communication needs, but since these needs have not yet been well identified, this cannot be checked. News control is possible in several ways: (a) DFR has a facility for keeping a standing retrieval question in the DFR, making it posible at each execution time to retrieve the new objects satisfying the retrieval question which had not been retrieved the last time. (b) DFR has creation-date and last-modification-date on objects, so that a retrieving GCUA can easily retrieve the new items which have arrived or been modified since the last connection. DFR does not at present have any automatic facility for purging old messages to give room for new messages. This was not regarded as desirable in a typical office environment. A purge date, that is a date after which an object can but must not be removed, is however available. Probably, an automatic or semi-automatic purge facility will be needed if DFR is to be used for computer conferencing storage, and this is probably the largest problem with using DFR for group communication. DFR does not present any general distributed data base facility, with coordination of data bases in several places (for example similar to what has been discussed fo the DS using shadowing and caching) and this might also be a problem for group communication use of the DFR. Report from the subgroup on MOTIS (=X.400) ------------------------------------------ I spent my time in the subgroup on MOTIS, and within that in the subgroups on Group Communication and on the Message Store. Group Communication (Computer Conferencing etc.) is a new work item (at present for balloting to the ISO members) to be handled in cooperation with CCITT during the next study period. To start the work I had prepared an input paper, with a detailed list of functions available in existing computer conference systems, describing 48 different functions. This paper was discussed in the subgroup. We made some modifications, and decided to make the paper into a working document within WG 4 and send it to WG 1 for comments on user requirements. The modifications were to remove a few paragraphs which were describing technical solutions, since the paper at this stage should only describe functions, not technical solutions. We also changed the word "computer conferencing" to "group communication activity" in order to avoid a too restrictive interpretation of the term. Message Store ------------- The message store is a service for storing the incoming messages to a user temporarily at a central location and allowing the UA to retrieve selectively messages from it. It is not a general- purpose message data base service. It is part of the X.400/MOTIS standard. Previous versions of it had an inlog/outlog facility (a log of which messages have come in and been sent out). There is now interest in adding this facility again to the standard, at least in the ISO version, especially since people working with EDI (Electronic Data Interchange, the use of X.400/MOTIS for the transfer of formatted data) wants this. We did some work during the WG4 meeting on how to add this facility to MOTIS. The most difficult point of work on the inlog and outlog was the so-called auto-correlation, which is a facility for automatically processing incoming notifications and creating from them, in the outlog, on each outgoing message a data structure describing which of the intended recipients have got and have not got the message. Our result is that there is going to be a number of new outlog fields. All of these fields will have at least one value for each intended recipient: Auto-correlation-delivery-report-request (contains information about which delivery reports were requested). Auto-correlation-deliver-report-result (contains a very compact summary of whether each intended-recipient has received the message). Auto-correlation-delivery-report-list (contains for each intended recipient, a list of the incoming delivery reports) Auto-correlation-non-delivery-report-list (the same for non- delivery-reports) Auto-correlation-receipt-report-request (corresponding for receipt reports) Auto-correlation-receipt-report-result Auto-correlation-receipt-report-list Auto-correlation-non-receipt-report-list Auto-correlation-reply-report-list The auto-correlation-delivery-report-result will for each intendend recipient contain an integer value as follows: 1 = Non-delivery-report arrived from the intended recipient 2 = Delivery-report arrived from the intended recipient 3 = Non-delivery-report arrived from indirect recipient 4 = Delivery-report arrived from indirect recipient 5 = No report has yet arrived If reports arrive indicating different values of the setting of this value, the lowest value has highest priority. For auto-correlation-receipt-report-result, the corresponding table is: 1 = Non-receipt-report 2 = Receipt-report 3 = Reply-report 4 = No report yet received A controversial question was to what extent a user should be able to control the logging. We tentatively chose the maximum flexibility, but this may be unnecessary complexity. Thus, for each message, a user can give flags to require: - No outlog for this message - Outlog, but no auto-correlation - Outlog and autocorrelation, but incoming notifications will still be regarded as new items - Outlog and autocorrelation, and incoming notifications will be handled as processed It will also be possible to register a default value for the above settings to be assumed if a user does not indicate any special request at message-submission. The subgroup on routing and management had noted that an MTA may sometimes get conflicting advice on the best route to use from different routing-information-servers. There is no good algorithm in such a case for choosing which route to use. Notes from the final plenary ---------------------------- ISO/IEC JTC 1/SC 18/WG 4 will ask for a new work item on EDI (Electronic Data Interchange) in MOTIS, and will start to liaison with CCITT immediately on this subject. The following liaison letter was sent to CCITT: ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- Liaison letter From: ISO/IEC JTC 1/SC 18/WG 4 To: CCITT Interim rapporteur group om EDI in X.400 Topic: Cooperation on EDI in X.400/MOTIS ISO/IEC JTC 1/SC 18/WG 4 will propose a new work item within ISO/IEC JTC 1/SC 18 on the conveying of EDI information within MOTIS. ISO/IEC JTC 1/SC 18/WG 4 is prepared to begin immediate cooperation with CCITT in the development of such facilities within MOTIS/X.400. ISO/IEC JTC 1/SC 18/WG 4 is planning to send liaison representatives to the next meeting with the CCITT interim rapporteur group on EDI in X.400, and we invite CCITT also to send liaison representatives to ISO/IEC JTC 1/SC 18/WG 4. The next meeting will be in Barcelona in January 1989. As an appendix to this letter, we include a question on the scope of EDI uses within X.400/MOTIS. This is an item for further discussion and on which joint agreement between CCITT and ISO will have to be reached. Appendix: Question on the scope of use of EDI within X.400/MOTIS. We understand that the main intention of the use of EDI within X.400/MOTIS is to use X.400/MOTIS as a vehicle for the transport of batch type operations between host computers. There is, however, also a need within X.400/MOTIS to send messages which partly contains application-specific formatted fields. A user workstation might be used to fill in a form on the screen to be sent via X.400/MOTIS, and to be alternately processed by humans and machines, like for example travel expense handling. Such messages may often partly contain ordinary text, like a description or motivation, and partly fixed-format fields. The question we want to clarify is whether the new content-type for EDI within X.400/MOTIS is to be used also for this kind of messaging applications, or whether it is more appropriate to do this for example via extensions to ODA in P2 body parts. If extensions to ODA is to be used, should the EDI format, embedded in ODA, be used? ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- We decided to write a letter to ISO member bodies, asking them which work items should be taken up jointly between ISO and CCITT on future work on MOTIS in the next study period, and how cooperation between ISO and CCITT should be handled. This will be used as input to SC 18/WG 4 in its January meeting, in preparing a liaison letter to the opening plenaries of CCITT Study Groups VII and VIII. A large controversial problem in the DOAM group was whether RDT (Referenced Data Transfer) is to become a new work item and a separate standard, or a part of DOAM. Two member bodies required that it should be a separate work item, because they say this will ensure coordination with SC 21 work in the same area. A very bysantine compromise solution was reached, which I did not quite understand, but which seemed to mean that those who wanted RDT as a separate work item and separate standard got what they wanted, but that final decisions was delayed. ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- The next three meetings with ISO/IEC JTC 1/SC 18/WG 4 will be: January 16-25 in Barcelona May 22-31 in Stockholm October 2-11, tentative date, venue not decided