From: jpalme@heron.dafa.se (Jacob Palme SKHB)
Newsgroups: comp.protocols.iso.x400
Subject: (none)
Date: 7 Oct 92 15:40:30 GMT
Article-I.D.: heron.9210071540.AA08683

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.