JPALME@com.qz.se (10/17/89)
bcc: "MHS (CCITT) Standardization" <C333@QZCOM.QZ.SE>,
iso-messaging-group@RUTHERFORD.AC.UK
Notes from the Bari meeting of the ISO messaging group
======================================================
The ISO/IEC JTC 1/SC 18/WG 4/Special working group on messaging
has just held a meeting in Bari in Italy between October 2 and
October 6, 1989. Here are my personal notes from the meeting.
CCITT cooperation
-----------------
There are two different international organisations who develop
messaging standards, CCITT and ISO. This is of course not very
good. The ISO group has therefore proposed to CCITT that we
should hold joint meetings with the technical group developing
messaging standards in ISO and in CCITT, in order to ensure that
the ISO and CCITT standards will be as similar as possible.
This proposal has not been accepted by CCITT. We therefore now
proposed an alternative, to hold co-located meetings, with common
groups for the technical work on those issues where both
organisations agree on this, but with separate plenary meetings
at the start and end of the meeting. These separate plenaries
should be held in sequence, not concurrently, to allow liaison
officers from one of the organisations to participate in the
plenary meeting of the other organisation.
We wrote a letter to CCITT, where we tried to be as nice and
friendly as we could, in the hope that CCITT will recognize our
good will and accept joint or co-located meetings.
Resolution of defects
---------------------
We discussed a small number of defect reports on IS 10021 (the
ISO name for the X.400 recommendation). No final decision was
taken on them, since this must be in cooperation with CCITT, and
we do not yet know if CCITT will accept co-located meetings with
ISO or not. Since defect resolution must be done in cooperation
with CCITT, this will be much easier if CCITT accepts co-located
meetings.
Enhancements to IS 10021 (X.400)
--------------------------------
The 1988 version of IS 10021 (X.400) has a built-in extension
facility, making it easy to add extensions without causing
problems for implementations without these extensions.
We decided to add a new message heading field, using this
extension mechanism. This field is called "auto-submitted mark",
and indicates whether a message was produced by, or under
supervision of, a human, or automatically bu a machine. This
field is useful, since you can avoid two machines interminably
sending messages back and forward to each other in an infinte
loop. There are also other uses of this heading field.
MHS Routing and Management
--------------------------
I did not participate in the subgroup on this, so I cannot report
in detail. The group is working on use of the directory system to
store information about how you can reach he recipient of
messages. MTA-s are expected to use the directory system to
decide where to forward messages they get.
They note that O/R-names are allocated by a hierarchical
structure of naming authorities. First, country name is allocated
by IS 3166 and X.121. Then, ADMD- and PRMD-names are allocated
nationally. ORG names are sometimes allocated nationally,
sometimes by ADMD and PRMD owners. All other name attributes are
allocated within ADMD-s, PRMD-s or ORG-s. Thus, a distributed
directory structure can be created based on this hierarchical
structure of naming authorities, and can contain as attributes
the routing information. Corresponding structures as described
above for mnemonic O/R-names can be built for Numeric and Postal
O/R-addresses.
The group discussed how this will work in special cases, like a
PRMD connected to two different ADMD-s in a country, possibly
with different PRMD name in relation to each ADMD.
The group wrote a liaison letter to SC 21 (the ISO standards
group which is responsible for the Directory System) telling them
their needs for use of the directory system.
Message Store Enhancements
--------------------------
The 1988 version of X.400 contains a facility called the Message
Store. It is a facility for storing messages for a particular
user, and giving the user some control on when to download
messages to his workstation. ISO is working on enhancing the
Message Store, so that it can be a fully qualified personal
message store, with folders, automatic filtering and sorting of
incoming messages etc.
Group communication
-------------------
By group communication is meant support for communication within
groups of people. ISO has identified about 50 different functions
in group communication systems, from basic computer conference
systems, to advanced systems with support for voting, joint
editing etc. At the Bari meeting we discussed the AMIGO model for
group communication and different system architectures. We
intentionally avoided any limiting decisions, because we prefer
to make these together with CCITT, but tried to clarify the
consequences of different solutions.
The main points of discussion at this meeting was the
architectural model and data model. The architectural model can
contain a Group Communication Service Agent (GCCA) which
indirectly makes use of other services like MTS, the Directory
System and the Document Filing and Retrieval System (DFR).
Another alternative is that the Group Communication User Agents
(GCUA) directly make use of these supportive services. We also
discussed the possibillities of defining group communication in
classes, each class being a subset of the next higher class. This
would allow easy implementation of the most basic group
communication services, with Class 0 equal to MHS/88 without any
changes, since also MSH/88 does contain some group communication
support through distribution lists.
Use of messaging for EDI
------------------------
We did nothing on this subject at the Bari meeting.
Representation of O/R addresses for human exchange
--------------------------------------------------
There is a need for a standardised format for writing the
electronic mail address, the so-called O/R-address, on business
cards, letter heads etc. in the same way as postal addresses and
telephone numbers. This is a very controversial area, because
some solutions which are easy to handle for humans require that
the user interface of message systems are capable of inputting a
concise format of the O/R-address. And many people are against
all standards which will influence the user interface of message
systems. The main controversy was between my standpoint, that we
should not totally preclude solutions which do mean some limited
requirements on the user interface, and the Canadian standpoint,
that we should not even investigate and test such solutions.
A psychological test will be performed in Sweden to compare three
different alterntives for writing an O/R-name. Here is an example
of an O/R-name in the three formats:
***** Full format:
Country = SE
ADMD = TEDE
PRMD = QZ
Organisation = Stockholm University
Organisational Unit = DSV
Given name = Jacob
Surname = Palme
***** RARE format:
C=SE;ADMD=TEDE;PRMD=QZ;O=Stockholm University;OU=DSV;GN=Jacob;SN=Palme
Note: If the RARE format is to be used, there is some discussion
on whether the character between label and value should be ":" or
"=". We thought that "=" would be better, since otherwise users
might find difficulty in distinguishing between the rather
similar characters ":" and ";". An alternative is also to use "]"
instead of ";" as separator, but this is not good, sice "]" is a
nationally defined character in the IA5 (ISO 646, "ASCII")
character set.
***** Concise format:
/Jacob/Palme//DSV/Stockholm University//QZ/TEDE/SE
On this controversial issue, Canada wanted to ask ISO member
organisations whether the work in this area should be allowed to
study solutions which may mean certain requirements on the user
interface of message systems, while I (representing Sweden) did
not want to put this question to ISO member organisations until
standards work and investigations had reach the so-called DP
(Draft Proposal) stage. A compromise solution was reached, in
which ISO member organisations were told of the conflict, but
also told that this choice requires careful study, and are then
given the option to give their opinions on this matter if they so
wish.
Next meeting
------------
We hope that our next meeting will be together with CCITT,
probably in January or February 1990. If this is not possible,
ISO will meet in Britain for a separate meeting with the ISO
messaging group.
grimm@darmstadt.gmd.dbp.de (Ruediger Grimm) (10/18/89)
I would like to suggest to the ISO messaging group to take the two
formats,
***** RARE format:
C=SE;ADMD=TEDE;PRMD=QZ;O=Stockholm University;OU=DSV;GN=Jacob;SN=Palme
***** Concise format:
/Jacob/Palme//DSV/Stockholm University//QZ/TEDE/SE
not as excluding alternatives. While the RARE format would cover the
needs of the Concise format, the concise format is still shorter and
has thus the advantage of the RFC822 format. It looks odd, if some
attributes are missing, and a sequence of /// and /-/ is confusing.
However, I agree, that in normal cases the concise format is indeed
concise.
On the other hand, the concise format does not cover all needs of
the RARE format. If the concise format is going to be standardized,
there is still a need for the RARE format, namely for all cases,
where portions of addresses are expressed, such as in technical
papers (e.g. to explain the concise format).
The keyword oriented format of RARE does also free us from a strict
ordering of the attributes (which has not been particularly recognised
so far).
Greetings --- RuedigerJPALME@com.qz.se (10/18/89)
>X-Originator: Jacob Palme QZ <JPALME@com.qz.se>
You are right in that the two formats do not preclude each other.
It is not very difficult to write a parsing program, which can
parse strings in both formats and separate the different or-name
components. So it is not at all unreasonable to expect messaging
systems to be able to input or-names in both formats.
The only problem is those systems which input or-names by a form-
fill in method. Both the RARE and the Concise format, but especially
the Concise format, requires that the messaging system can take
as one alternative input format (not necessarily the only format)
the string used in the RARE and Concise format.
The main advantages with the concise format are:
It does not contain very many concepts which normal non-expert
people do not understand, like ";ADMD=".
It contains, instead, mostly sequences which are natural to
normal humans. Just like in mathematics, you can write
1
- = 1/2
2
it is natural to replace things written on succeeding lines to
one line by "/", so use of "/" is intuitively natural and similar
to normal postal addresses.
The concise format intentionally uses very few funny characters.
Of course, to a person who is an X.400 expert, the concise format
is not good, because the X.400 structure is hidden. But the format
is not intended for X.400 experts, it is intendend for ordinary
humans.
Compare the following two addresses:
C=GB;ADMD="Gold 400";O="Nottingham University";S=Smith;G=Hugh
/Hugh/Smith//Nottingham University//Gold 400/GB
Then the second string will seem much more natural for a person
who is not an expert on X.400. The format contains mostly concepts
which are natural for such a person to think about, like
"Hugh", "Smith", "Nottingham University", "GB".
alf-hansen%vax.runit.unit.uninett@NAC.NO (Alf Hansen) (10/18/89)
Just a stupid thought: Why not use RFC 822 as a concise format? With the RFC 987 mapping rules for <space> etc? Thus we will get the globally aggreed RFC 822/X.400 address mapping rule as a very important side-product? I guess this is not a serious comment because then we will have repeated .. in the address like Hugh.Smith@Nothingham_University..Gold_400.GB Is this allowed in RFC 822? I am sure it is not. Sorry. Alf H.
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) (10/19/89)
Jacob, You should be very careful when you state that the concise format: /Hugh/Smith//Nottingham University//Gold 400/GB mostly contains ``concepts which are natural for such a person to think about, like "Hugh", "Smith", "Nottingham University", "GB"''. For this should be absolutely true of any ORName: it should contain mostly user guessable fields, like surnames or corporation identifiers. The only non guessable elements are the administrative domain name and the private domain name; your example which use only the ADMD name in the address, omitting the PRMD name, is thus slightly biased. In principle, if PRMD managers were following the naming philosophy of X.400 (sound pompous, doesn't it?), one would only have to precise the administrative attributes on one's business card: provided that Country, ADMD and PRMD are properly filled in, any ORName containing sufficient attributes to identify uniquely the person should work: the MTA should undertake a search in its local directory, and then identify the mail box. We all know that this is not the case. At least, this is not the case in our naming schemes, which were strongly influenced by the ``user-account at host'' addressing philosophy of the early computer networks. For example, a message bound to: <S=grimm; OU=darmstadt; PRMD=GMD; ADMD=DBP; C=DE> will reach its destination. But neither: <S=grimm; OU=darmstadt; O=GMD; PRMD=GMD; ADMD=DBP; C=DE> nor <G=Ruediger; S=Grimm; OU=darmstadt; PRMD=GMD; ADMD=DBP; C=DE> And, still, the address of Ruediger is amongst the most user friendly, as it does not contain arbitrary identifications of hosts (e.g. OU=KOMEX), and as the surname field is indeed a surname. Just apply the same reasonning to: /P11015/DDAVM07/BITNET/DBP/DE and the opinion on user friendliness will be somewhat different! All that means that the (pompous?) "naming philosophy of X.400" has vanished in the sands of reality. What we have in fact is a set of tokens, some of which guessable some others less guessable, which constitute an address and should not be mispelled, completed or depleted. Hence the need of a very precise notation, with key words et all. Christian Huitema