Path: utzoo!utgpu!watmath!att!rutgers!ucsd!usc!cs.utexas.edu!uunet!ncis.tis.llnl.gov!com.qz.se!JPALME From: JPALME@com.qz.se Newsgroups: comp.protocols.iso.x400 Subject: Notes from the CCITT X.400 group meeting in November 1989 Message-ID: <466568@QZCOM> Date: 20 Nov 89 17:25:00 GMT Sender: root@ncis.tis.llnl.gov Reply-To: Jacob Palme QZ Distribution: inet Organization: The Internet Lines: 272 Approved: post-x400@tis.llnl.gov >X-Originator: Jacob Palme QZ Notes from the CCITT X.400 group meeting in November 1989 --------------------------------------------------------- These are my personal notes, not official minutes. The CCITT rapporteaur group Q.18/VII met for its first meeting with technical work during the 1989-1992 study period in Rhodes, Greece in November 1989. (Note that the use of X.400 for EDI is handled by another, separate CCITT group.) Since this was the first meeting with technical work during the new study period, much of the time was spent to planning and setting the scope for work in the new study period. Here is a summary of the most important decisions. Representation of O/R-names for human exchange ---------------------------------------------- The group decided that this is a task for Study Group I, not Study Group VII, and will thus not do work in this area unless asked to do it by Study Group I. Collaboration with ISO ---------------------- CCITT Q.18/VII decided to accept the ISO/IEC JTC 1/SC 18/WG 4 special working group on messaging proposal to collaborate with ISO through co-located meetings. This will be done on a trial basis, if experience shows that it causes problems, CCITT can stop the cooperation. Another restriction is that co-located meetings will only be acceptable when a host, willing to host such a combined meeting, can be found. As one person said to me in a break "The ISO people had better behave, or we will throw them out again". Defect handling and implementor's guide --------------------------------------- Just like in the previous study period, a defect handling procedure will be set up and an implementor's guide, containing defect resolutions on X.400/88 will be published. Defects will be handled in collaboration with ISO. Defect reports should be sent to: Tim Bishop c/o ICL Six Hills House London RD, Stevenange Herts, SG1 1YB England For X.208, X.209, ISO 8825, X.228, ISO/IEC 9066-1/2, X.229, ISO/IEC 9072-1/2, X.407 and ISO/IEC 10021-3, defect reports should be sent to: Keith Rayner British Telecm Friars Hourse 2, Falcon Street Ipswich IP1 1FI Suffolk United Kingdom For x.403, defect reports should be sent to: Yves Ruggieri SEPT/SEC/SPM 42 rue des Coutures F-14066 Cean, Cedex, France Implementors, wishing to get a copy of the guide, should send their addresses to: Carl-Uno Manros Siemens AG, Dpt DISP Sys P.O. Box 830951 D-8000 Munich 83 Federal Republic of Germany A rather large number of defect reports were resolved at the meeting. X.400 Enhancements ------------------ There is large interest in changing to a more powerful character set than Printable String and IA5, such as T.61 or IS 10646. A migration strategy must be set out for changing to such a more powerful set. A new object-oriented approach to content type design may be used in the future. This will allow new content-types to download certain attributes from a library of cmmon content-type attributes, like Message-ID. Message Store Enhancements -------------------------- Several proposals were available for Message Store enhancements, both from CCITT members and from ISO working groups. The new proposals can be divided into two groups: (a) Small changes within the scope of the Message Store as it is. (b) Larger changes, which are intended to make the Message Store usable also for long-term storage of messages (but still for only one receipeint). These larger changes can be used using DFR (Document Filing and Retrieval) directly or indirectly. No decisions were reached. CCITT Study Group I will be asked to comment on user and service requirements. Maximum attribute length ------------------------ A problem with X.400/88, is that the maximum length of attributes are given in number of characters, not in number of octets. One character may be represented by only one octet, or by as many as four octets. Q.18/VII wants to be able to specify the maximum length in octets, but this requires a change in ASN.1, so aletter to Q.8/VIII and Q.19/VII was written requesting these changes. Security -------- The security group worked on the following problems: Proof of transfer between MTA-s, Proof of Retrieval from an MS by a MS user, "Token structure" and a number of smaller problems. ODA in IPMS ----------- ODA body parts are now awailable in IPMS. The specification is in T.411 (ISO 8613-1). File transfer ------------- The possibility of file transfer in X.400 is investigated. By "file transfer" is meant the carrying of computer programs, Spreadsheet worksheets etc in IPM or in new content types. Application Program Interfaces ------------------------------ The group did not make any decisions on whether we wish to be involved with the development of application program interfaces. There is a risk, since other groups are working in this area, of double work. If however, such interfaces are to be defined by CCITT, Q.18/VII thinks that Q.18/VII is best capable of developing such interfaces for the parts of MHS it is responsible for, and it thinks that these interfaces should be developed at the same time as the abstract syntax for the MHS functionality. Voice Messaging --------------- The voice messaging subgroup has not made up its mind on whether to use P22 or a new content type for communication between voice messaging systems. Computer Conferencing and Bulletin Boards ----------------------------------------- The group on this area mostly discussed scope. It decided that synchronous computer conferences is not within our scope. Within our scope, we defined five scenarios of increasing functionality. We went through a number of user functions from an ISO input document and categorized them according to the five scenarios. We also produced a user requirement input, and wrote a liaison letter to SG I asking for guidance on user requirements in this area. The five scenarios are: Scenario 0 ---------- *Time frame*: Available now. *Impact on recommendations*: Identical to IPM/88, using the group communication support already available in existing recommendations. *Functions provided*: The distribution list facility of IPM/88 can be used to deliver messages between activities (bulletin boards). The functions provided by different activities will be a local matter not covered by the recommendation. Access control to activities will largely be a local implementation matter. Owners of X.400/88 systems without enhancement with group communication functionality will be able to participate via the distribution list facility. Scenario 1 ---------- *Time frame*: Recommendation easily ready within the 1988-1992 study period. *Impact on recommendations* (in addition to scenario 0): Extend P22, or design a new content type, in order to accomodate names for group activities, and provide capabilities for conveying group structuring information between UAs. *Functions provided* (In addition to scenario 0): Users will be provided with a uniform and globally unique name for an activity. Moderators will be able to remove unsuitable messages from an activity, even when the activity has a distributed representation. Messages can be moved from one activity to another. Encryption to increase the security of an activity will be possible. Roles may be used when submitting messages to activities. Scenario 2 ---------- *Time frame*: Possible recommendation during the 1988-1992 study period. *Impact on recommendations* (in addition to scenario 1): Directory system support for group communication. *Functions provided* (in addition to scenario 1): Users will be able to search for, join, withdraw from and submit messages to a distributed activity without knowing the nesting of distribution lists behind it, and using a globally unique directory name when referring to the activity. Directory system access control facilities can be used to control who may create, join, read, write and perform other functions on an activity. Roles may be used to provide additional access control. Scenario 3 ---------- *Time frame*: Possible with hard work and enough resources within the 1988-1992 study period. *Impact on recommendations* (in addition to scenario 2): A multi- user message store. *Functions provided* (in addition to scenario 2): New members of an activity will be able to read messages written before they joined the activity in a standardized manner. There will be a standardized way of connecting to an activity so that users with a UA from one vendor may connect this UA to a multi-user store from another vendor and browse and read messages from the store. Users will be able to re-download previously seen messages from an instance of the joint store which stores a copy of this activity. Standardized ways of controlling filters, which select and order messages according to the wishes of a user can be provided. Scenario 4 ---------- *Time frame*: Probably not ready until in the next study period (1992-1996). If so, final decision on whether to study this will be done when the questions for the next study period are defined. *Impact on recommendations* (in addition to scenario 3): Addition of support for specially customized group communication procedures. *Functions provided* (in addition to scenario 3): Support for voting, joint authoring and production of documents. Standardized support for constructing enhancements with new, specially defined group procedures not explicitly thought of in the recommendations.