Article View: comp.protocols.iso.x400
Article #593(none)
From: Jacob Palme SKHB
Date: Wed, 07 Oct 1992 15:40
Date: Wed, 07 Oct 1992 15:40
173 lines
6793 bytes
6793 bytes
Notes from the ISO/CCITT messaging meeting in Oslo, September-October 1992. This is the group which is responsible for maintenance of the MHS (X.400) messaging standards. Here are my personal notes, they are not official minutes from the meeting. Some of the output papers from the subgroup which I participated in, the group communication subgroup, will be sent separately. We split up into six working groups: - Group communication - Message store extension - General enhancements - Defect reports - Voice communication - Fax communication Group communication ------------------- A problem with group communication work in ISO/CCITT is the large turnover of representatives. At this meeting, for example, there were five people in the group communication subgroup. Three of them had never before participated in this group, one of them had participated in one meeting before, and one (me) has participated regularly for several years. This means that at every meeting we will have to redo work which has already been done before. As one example, several participants at the present meeting asked for work on defining the user requirements. this work was however done several years ago, but is now forgotten. As another example, one of the most controversial issues in group communication is whether to use a master copy method of updating the group communication (as in the DS, there is one master copy of each information object and updates of it must always start with the master copy) or whether to use copy-and-forward updating, where updates can be done on any service agent, and will then be copied to neighbouring service agents until the change percolates to every service agent holding the updated object (a technique used by Usenet News). For several years the majority of the representatives in the group communication ad hoc subgroup has favoured the master copy method at updating. (I personally think that both methods should be supported, but I have always before been in a minority in the group.) Now, suddenly, there is a large majority for the copy-and- forward method of updating! So now we will all go home and redo our models to support the copy-and-forward method of updating. And then, perhaps, at the next meeting, there will again be a majority for the master copy method, so that we will again have to redo our working documents! This problem would not occur, if mostly the same people would come to the group communication subgroup every year. At the present meeting, much of the work concentrated on a proposal from Japan to define a standard for group communication with functionality very close to that offered by the Usenet News service. I personally, because of my experience from the KOM, SuperKOM and EIES 2 conferencing systems, would prefer a more powerful standard than just copying the Usenet News service. The Japanese representatives are not opposed to this, but they then want us to develop two standards, one for the Usenet News kind of service and one for a more advanced standard. I am not against providing a Usenet News type of service as a subclass of the group communication standards, but would then prefer as much as possible to be identical in the two versions of the standard. Management information exchange =============================== We are close to getting ISO approval for a new work item on "asynchronous exchange of management information via MHS". For such management information which is not time critical, it may be less costly to exchange them via MHS. In order to do this, certain problems on mapping the management protocols onto MHS need to be solved. Routing ======= The routing group had among other things discussed problems with O/R-addresses in different character sets, since a router must be able to route on the O/R-address even if it is not only in the Printable String character set. A protocol is under development for interchange of Routing Elements for the establishment of routes between MTA-s. A routing-element is a way for an MTA to tell other MTA-s of its routing-capabilities. The Directory will also be used to store routing information. A new feature added at this meeting was a Route Weighting Attribute to distinguish on preference between otherwise identical Route Indicators which represent alternative routes to the same destination. Telephone access to MHS ======================= Many message systems today provide access via the telephone network, but there is no standard in MHS on how this should work. To enable phone access, problems on error handling, efficiency, transparency, flow control, consistency and multiplexing need to be investigated. Voice body parts ================ Defects were corrected in the voice body part ASN.1 encoding. Security ======== Security issues of MHS management were investigated. Message Store ============= Work was begun on ways to transfer messages from the Message Store (which is a single user mailbox data bases) to the Document Filing and Retrieval service, DFR (which is a multi- user office document store). A number of minor problems with the P7 protocol were corrected. Defects and ASN.1 updating ========================== The same people work on correction of defects in X.400 and on updating the ASN.1 usage in X.400 to the new ASN.1 version where macros have been replaced by new features. Because there is so much work on defects, the people complained, they had no time to spend on the work of updating the usage of ASN.1. To solve this problem, they may have to have separate extra meetings to work on the ASN.1 updating problem. No PICS will be developed ========================= It was noted that JTC 1 has now decided not to develop any new PICS for the latest versions of X.400. PICS are tables, where you can fill in which the capabilities of various software products are. No one has time to develop the PICS. Forthcoming meetings ==================== The next meeting with ISO/IEC JTC 1/SC 18/WG 4 and CCITT VII/Q.18 will be in Tokyo, beginning on February 3, 1993. Some subgroups (Group communication and others) will begin the meeting on February 1. After that, the next meeting will be beginning in the last week of June, 1993, probably in Geneva.
Technical Details
Message-ID:
<9210071540.AA08683@heron.dafa.se>Path:
arc1-ca.pugleaf.net!sparky!uunet!ogicse!uwm.edu!zaphod.mps.ohio-state.edu!usc!news.service.uci.edu!ucivax!gatewayShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!ogicse!uwm.edu!zaphod.mps.ohio-state.edu!usc!news.service.uci.edu!ucivax!gateway From: jpalme@heron.dafa.se (Jacob Palme SKHB) Newsgroups: comp.protocols.iso.x400 Subject: (none) Message-ID: <9210071540.AA08683@heron.dafa.se> Date: 7 Oct 92 15:40:30 GMT Article-I.D.: heron.9210071540.AA08683 Lines: 173 Approved: usenet@q2.ics.uci.edu