🚀 go-pugleaf

Notes from the ISO/IEC/CCITT X.400 development group
====================================================
Geneva, November 12-21, 1990.

The collaborative meeting between CCITT Study Group
VII/Question 18 and ISO/IEC JTC 1/SC 18/WG 4 Special Working
Group on Messaging has just finished in Geneva. Here are my
personal notes from the meeting, this is not the official
minutes of the meeting.

X.435 final (?) editing
-----------------------

More than a hundred reports of bugs and deficiencies in X.435
(the standard for carrying EDI in X.400) were handled.

A controversy on how the content type for EDI should be given
in the P1 envelope was handled. The decision was to use only
the integer 35, and not any object identifier. This makes
things simpler, even if some fundamentalists may not like the
decision.

X.400/88 defect group
---------------------

The X.400/88 defect group also handled a large number of
defects in X.400.

General enhancement group
-------------------------

One major point of discussion in the General enhancement group
was how to use X.400 for communication between multi-telefax
senders. Example: A sender in Europe wants to send a fax to 10
U.S. recipients. He delivers the fax to a European multi-fax
vendor, who puts the fax into an X.400 message sent to an
American multi-fax vendor, who will then distribute the fax to
its recipients.

A controversial issue was how to handle delivery notifications
for messages from X.400 to be delivered as fax. The present
standard says that a delivery notification should be sent when
the message is turned over from the X.400 MTS to the Access
Unit (=Fax sender). An American contribution wanted to send
delivery notifications instead when the fax had been
successfully delivered to the recipient fax machine.

The decision was that for the special case of store-and-forward
fax service (described above) two notifications will be
produced, one at delivery to the remote fax sender and one at
the delivery to the recipient fax machine. The latter will
probably look like a recipient notification and will be called
"rendition notification".

My proposal to allow conversion between P2 and P22, entered
after discussion here in the MHS News mailing list, was
rejected without reason.

About two years ago, I sent in a proposal to add to the IPM
heading an "auto-submitted" indication when a message had been
automatically generated by a machine has gone through a curious
history. At two previous meetings, the enhancement group had
decided that this should go into the P1 envelope, not into the
IPM heading. But now, they had changed their mind again, and
moved it back to the IPM heading as I originally proposed.

A proposal was accepted to help accounting in P1 by indicating
in a simple way in the envelope if a message is any of several
different kinds of notifications (which maybe should be billed
on the recipient of the notification) was accepted. This
proposal can be implemented also in 1984 X.400 systems.

Another topic in the general enhancement group was file
transfer in MHS. The group has decided to suspend development
of file transfer as a separate content type, and concentrate
work on file transfer as an IPM body type. This body type will,
in addition to the file itself, contain certain parameters on
the file taken from FTAM. These parameters are:
- filename
- permitted actions
- contents type
- date and time of creation
- date and time of last modification
- date and time of last read access
- identity of creator
- identity of last modifier
- identity of last reader
- filesize
- future filesize
- legal qualifications
- private use

The following issues are not yet resolved for file transfer in
MHS:

- How detailed should the contents type be (e.g. binary file,
spreadsheet or Lotus 1-2-3 ver. 5.0).

- Is there a requirement for multiple File Transfer body parts?

- Are the security elements-of-service currently defined in
X.400 sufficient for file transfer?

The Message Store enhancement subgroup
--------------------------------------

This group has been a very controversial group, because the
British delegation very strongly favours a lot of enhancements
to the Message Store, in order to make it useful for long-term
storage of messages. Among the many ideas are folders and
automatic filters to sort incoming messages into different
folders according to their attributes.

This proposal has been opposed by most other countries. Their
main reason is that they do not want to extend a new standard
so much and so soon, since this may stop implementors from
implementing it. Also, they feel that the MS should not be
extended to become a competitor to DFR (Document Filing and
Retrieval), in order to avoid having more than one standard for
similar purposes.

The following extensions to MS have been accepted:
- Storage on submission.
- Stored message tagging.
- Stored message auto-modification.
- Storage of draft messages.
- Stored message lapsed time.
- IPM-stored message purging.
- Inlog and Outlog.
- Auto-correlation of reports.
- Auto-correlation in IPM.
- Auto-correlation in Pedi.

The following extensions are not accepted:
- Stored message timed alert.
- Submission of stored messages.
- Forwarding history.
- IPM auto-obsoletion.

No decision could be taken on extending the MS with "Non-
repudiation of retrieval" since no security experts
participated in the meeting.

A rather sharply worded liaison letter was sent to the
Directory Group, because this group had changed the filter
definition (which is used also in the message store) without
liaison with the MHS group.

Visual representation of O/R addresses
--------------------------------------

The group on this have now agreed on a modification of the RARE
format for writing O/R addresses on business cards etc. This
will probably soon be sent out for balloting to ISO member
bodies, probably in February 1991, immediately after the
meeting with the X.400 development group there.

The standard will propose to formats for O/R-names. One short
format, which may e.g. look like this:

X.400: G=nigel; S=bevan; O=ucl; P=uk.ac; A=gold 400; C=gb

and one longer format which is language dependent and may look
like this:

Country (C):            GB
ADMD:                   Gold 400
PRMD:                   UK.AC
Organisation (O):       UCL
Org. Unit (OU):         ESS
Surname (S):            Bevan
Given name (G):         Nigel

The text outside the parenthesis will vary with language, the
abbreviation in parenthesis will always be as given above.

Two issues are yet unresolved:

(a) Should the delimiter between fields on a single line be ";"
or "/".

(b) In which order should the elements of the name be given.
One of the following orders will be used:

G S O P A C (advantage: More like postal addresses, with the
smallest unit first).

C A P O S G (advantage: No problem with ordering of OU-s).

Group communication group
-------------------------

I will report in a separate message from this group, in which I
myself participated.

Other groups
------------

Work was also done in a group on MHS Management and routing,
and a group on voice messaging.

Future meetings of the X.400 development group
----------------------------------------------

13-22.2.91 in Wollongong, Australia.

19-28.6.91 in Ottawa, Canada

16-25.10.91 somewhere in Europe.

An interim group may meet, if needed, in February 1992.