[comp.protocols.iso.x400] Notes from the CCITT X.400 group meeting in November 1989

JPALME@com.qz.se (11/21/89)

>X-Originator: Jacob Palme QZ <JPALME@com.qz.se>

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.
     
     

JPALME@com.qz.se (11/30/89)

>X-Originator: Jacob Palme QZ <JPALME@com.qz.se>

In the message, to which this is a reply, i wrote that
"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."
     
People have reminded me that this wording can be mis-interpretet,
since the word "collaborate" in standards terminology may be
interpreted as "joint meetings", something which CCITT has
not accepted.
     
The difference between joint meetings, and co-located meetings,
is that in joint meetings also the plenary meetings are joint,
while in co-located meetings, only those ad hoc subgroup meetings
are joint where this is acceptable to both organisations.