JPALME@qz.qz.se (Jacob Palme QZ) (11/26/90)
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.
JPALME@qz.qz.se (Jacob Palme QZ) (11/26/90)
Here is the complete text of the minutes which I wrote during the
discussions in the computer conferencing/group communication
subgroup at the ISO/IEC/CCITT meeting.
SOURCE: Joint ISO-IEC-CCITT Group Communication subgroup at the
co-located meeting of CCITT Study Group VII/Q.18 and ISO/IEC JTC
1/SC 18/WG 4 SPG on Messaging, Geneva, November 1990 (Jacob Palme,
notetaker)
TITLE: Notes from the Group Communication Subgroup
STATUS: These notes mainly present the discussions within the
subgroup, not the final decisions made by the group. The final
decisions made by the group are recorded in a separate status
report from the subgroup.
Wednesday, November 14, 1990
============================
List of participants
Steve Benford, University of Nottingham, Nottingham, United Kingdom
NG72RD (Chairman of the group)
Michael Durkin, Bell Atlantic, One Parkway, 9B, Philadelphia, Pa
19102, U S A.
Ank Hoang-van, France Telecom Cnet, 38/40 General Leclerc 92131
Issy Les Moulineaux, France
Michael Kuna, Herrenhausstrasse 10, D-1197 Berlin, Germany
Hiromiki Moriyama, NTT-PC Com, 3-23-11 Nisahi-shinbashi, Minato-ku,
Tokyo 105, Japan
Jacob Palme, Skeppargatan 73, S-115 30 Stockholm, Sweden
Jean Walravens, Alcatel Bell Telephone, Francis Wellesplein 1, B-
2018 Antwerpen, Belgium
Ulrich Zysset, Swiss Ptt/KS 3, Viktoriastrasse 21, 3030 Berne,
Switzerland
List of contributions
TD 4019: Meeting report from the GC subgroup in the previous
VII/Q.18 meeting in Munich.
TD 4020: Draft recommendation F.gc, version 3 (output of the Munich
meeting)
TD 4021: Draft recommendation X.gc, version 3 (output of the Munich
meeting)
TD 4022: GC issues and requirements, version 3 (output of the
Munich meeting)
TD 4097 Asynchronous Group Communication, liaison letter from SG I.
This letter has two appendices:
1. Draft recommendation F.agc, version 4
2. Functional specification for a typical computerized
conferencing application
D-210: Draft recommendation X.gc, version 4 (from Sweden)
D-211: Draft recommendation F.gc, version 4 (from Sweden)
D-269: Comments on the standardization of Group Communication (from
NTT, Japan)
D-300: Group Communication Information Model and Abstract Service
(from UK)
D-308: Direction for Group Communication (from UK)
MH-300: Different Group Communication Implementations (from Jacob
Palme, Sweden)
MH-301: Contribution on Draft Recommendation F.gc/X.gc (from
Michael Kuna, Germany)
GC-1: Why Attribute Carriers (from Jacob Palme, Sweden)
Planning of work during this meeting
1. Identify output and timetable for this study period
(Input paper D-308)
2. Relation to other work (Input paper 4097)
3a. Technical issues, information model (Input papers
D-210, D-211, D-300, GC-1)
3b. Technical issues, architecture (Input papers D-269,
MH-300, MH-301)
4. Issues reflecting on the MTS (restriction on distribution)
5. Identify what we need for the next meeting
Resolution of different requirements on the GC work
We noted that there are two different and possibly conflicting
views on the output wanted from the group communication work:
a. That we produce a general-purpose group communication model
and framework, which can form as the basis for different group
communication applications. This general model and framework should
not be restricted to modelling group communication as part of MHS.
b. That we produce, if possible within the present study
period, a recommendation/ standard for the interconnection of
computer conferencing system, which has a close relation to MHS.
We made a tentative decision to resolve this problem by planning to
produce three documents before the end of the present study period:
Part A: Service specifications and user functionality
(corresponding to the F.gc document)
Part B: A general framework document. This part can contain:
> A general information model
> A general architecture model
> A general management model
> A general description of user operations
Part C: Computer conferencing. This part can contain:
> How to apply the models in document A on computer
conferencing
> User operations in computer conferencing
> The specific model, architecture and protocol for
computer conferencing
Planning of future work during the present study period
Our goals (as seen at this stage of the subgroup meeting) would
then be to produce, during the present study period, Part B to CD
and CCITT draft recommendation status, Part A and C to CD and CCITT
recommendation status. The reason why part B would not go to DIS
status is that we expect that the 1992 CCITT recommendation will be
restricted in scope and functionality, and that ISO will want to
extend the scope and functionality together with CCITT in the next
study period. (See the status report for the final goals agreed at
the end of the subgroup meeting.)
Discussion of other work
We noted that work on synchronous group communication is presently
being done in SG I. We accepted that our results in part C
(computer conferencing) will be mainly aimed at asynchronous group
communication. We decided to write a liaison letter to SG I
presenting the above plans and asking for their approval. We also
decided to ask SG I for liaison from the present work on
synchronous group communication.
First pass at discussion of information model
We discussed the information model, mainly as presented in the
input papers D-210, D-211, D-300 and GC-1, noting the similarities
and differences in view on the information model.
Thursday, November 15
=====================
Future plans
Carl-Uno Manros visited us and said that there is no requirement
that we must be ready with a standard within the present CCITT
study period, but that he does require us to decide, before the end
of this meeting, whether we plan to have something ready for
approval as a CCITT recommendation within the present study period.
We decided to postpone a decision on this until Knut Smaaland can
join our group next week.
Restricted domain
We decided to write a letter to the Q.18 plenary, asking the
plenary to transfer responsibility for the function "restricted
domain" from us to the general enhancements subgroup. Jacob Palme
will draft a letter.
What kind of standards should we produce
We had a long discussion on what kind of standards we are to
produce. One alternative would be to produce the standards document
in three pieces:
A. A general definition of a group communication information
model, general architectural model and abstract service
specification.
B. A definition of computer conferencing, its abstract service
specification and how it can be realized using the general model
produced under A. above.
C. A realization of the general model produced under A., as it
can be used for computer conferencing, using partly existing
services like MTS, DS and DFR.
Another alternative would be to only produce the document B and C
as listed above, with direct specification of how B can be realized
using C.
A third alternative would be to specify A, B and C, but to define
the mappings not only from B to A and from A to C, but also between
A and C.
We made the tentative decision to try to develop this, but to be
prepared to skip the A. model if it is found to difficult or
unsuitable.
Plans for work during the present meeting
We decided to plan our work during the present meeting as follows:
Thursday afternoon: Computer conferencing model.
Friday morning: General GC model and mapping of the computer
conferencing model on it.
Monday: Summary of work during the previous week and work on the
realization using (wholly or partly) MTS, DS and DFR.
Tuesday: Concluding work, editing.
Computer conferencing model
Operations:
Role: Member
Subscription-request/Unsubscription-request (on an activity, a
conversation or a conversational branch).
Find-activities
Find-subscribed-activites
Find-contributions (includes finding contributions which are
unread, which are replies, directly or indirectly, to another
contribution etc.)
Fetch-contribution (in order to read it, print it, file it, filter
it etc.)
Re-submit a contribution (not necessarily self-written, to another
activity)
Add/remove keyword from a contribution
Find-members of an activity
Lookup information on another participant
Submit contribution
Reply to all recipients of a previous contribution
Reply to only the author of a previous contribution
Write a contribution obsoleting a previous contribution
Delete a contribution
Moderator operations
Pre-moderation:
Find-submission
Fetch-submission
Accept/reject submission (whether or how to notify the submitter is
FFS)
Re-route submission (to another activty)
Post-moderation:
Remove or reroute contribution (may include automatic removal or
rerouting of the conversational branch started by the contribution)
(Note that removal does not mean physical removal of the
contribution text itself, since the contribution may still be
available e.g. in other activities or to its author)
Owner/General manager operations
Set access controls.
Decide which entities or roles are allowed to copy, reroute or
remove contributions from an activity.
Create activity and sub-activity.
Delete activity (This may not imply physical removal of the
contributions in the activity, since they may be available as
contributions in other activities and to their writers).
Modify-activity (Some, but not all, attributes which can be
modified are expiration time, access controls, description, name,
aliases, keywords, rules, encryption policy, suspension status).
Add/remove members from activities.
Add/remove owners from activities.
Register and deregister users.
Notification handling
At least he following notifications may be needed:
Notification of acceptance and rejection of submissions to pre-
moderated activities.
Notification that you have become a member of an activity.
Delivery notifications to the conference and to its members.
Receipt notification.
Issues for further study in the above operations list:
Notifications and their use
Naming scheme
Handling of anonymous or pseudonymous contributions
How to announce new activities to potential members
Filtering
Setting keywords on activities
Friday, November 16
===================
On Friday we discussed the general group communication model. Steve
Benford presented his model. The general opinion was that we should
develop such a model, but that such development was a long term
task, and that we would in parallel develop a computer conferencing
abstract service definition and implementation based on MHS.
We also decided to produce liaison letters to SG I (regarding
future work on the F document) and to Q.20/ISO SC21/WG 4 on use of
the directory for group communication. (Later in the meeting we
decided not to produce any liaison to the Directory Group yet,
since our work on how to use the DS is not complete enough to
present to them.)
Monday, November 19
===================
On Monday, we discussed the Computer Conferencing Information
Model, Abstract Service definition and Architecture. The results of
this discussion can be found in our working paper, X.gc version 5,
part 3. Important issues during the discussions on Monday were to
what extent Computer Conferencing is to rely on the existence of a
globally interconnected Directory System and which underlying
services are best used for communication between GCSA-s.
We then decided to produce the following output documents from this
meeting:
Document Who will prepare a draft
-------- ------------------------
X.gc version 5 Jacob Palme with input from
Steve Benford
GC subgroup notes Jacob Palme
Liaison letter to SG I Jacob Palme
Restricted Domain proposal Jacob Palme
Timetable and status report Steve Benford
We then made the following table of documents which we would like
to see for the next Q.18 meeting:
Document Who is willing to work on this
-------- ------------------------------
Abstract service for
computer conferencing Jacob Palme, Steve Benford and
including ASN.1 encoding Michael Kuna
Distributed architecture Jacob Palme and Michael Kuna
for GC
General GC Information Model Steve Benford, Michael Durkin and
Jacob Palme
Computer Conferencing Steve Benford, Michael Durkin
Information Model and Jacob Palme
We decided to radically change the text in X.gc version 4 to show
how computer conferencing operations and architecture can be
derived in a top-down fashion from the computer conferencing
abstract service definition. Since we did not have time to finalize
this work during the present meeting, we will not copy the old text
of X.gc into the output working document, even though parts of the
ideas in this document will have to be handled in the final X.gc
document.
Tuesday, November 20
====================
Tuesday morning was spent on the general information model. We
especially discussed whether links are objects themselves or only
relations between objects.
On Tuesday afternoon, we went through a paper with functional
requirements on group communication coming from the the EIES
development group in New Jersey. We checked their requirements
against our requirements, and added proposals for new requirements
where needed.JPALME@qz.qz.se (Jacob Palme QZ) (11/30/90)
The message whose message-ID is given in the References clause
in the heading of this message was sent by me to
<MHSNEWS@VAX.runit.unit.uninett>
on Sunday, 25 november, 1990 at 18:11.
The message has arrived at some people in the U.S. because I
have recieved questions from them on it.
The message seems, however, not to have come back here to
QZCOM, we have a subscription to get it downloaded to
us with, I believe, the address
<EANNEWS@QZ.QZ.SE>
Have you any idea why it never got back to us?
Here is the full text of the message for your information:
(525662) S|ndag, 25 nov 90 18:11 Jacob Palme QZ
F|r k{nnedom: Robert A. Flavin <RIBO%YKTVMH.BITNET@CUNYVM.CUNY.EDU> -- S{nt: Ti
sdag, 27 nov 90 16:53
Ind. mottagare: Bj|rn Carlsson QZ
Ind. mottagare: MHS news distribution list <MHSNEWS@VAX.runit.unit.uninett>
Kommentar till l{sarna av: 525660 av Jacob Palme QZ
[rende: Notes from the ISO/IEC/CCITT X.400 development group
------------------------------------------------------------
Here is the complete text of the minutes which I wrote during the
discussions in the computer conferencing/group communication
subgroup at the ISO/IEC/CCITT meeting.
SOURCE: Joint ISO-IEC-CCITT Group Communication subgroup at the
co-located meeting of CCITT Study Group VII/Q.18 and ISO/IEC JTC
1/SC 18/WG 4 SPG on Messaging, Geneva, November 1990 (Jacob Palme,
notetaker)
TITLE: Notes from the Group Communication Subgroup
STATUS: These notes mainly present the discussions within the
subgroup, not the final decisions made by the group. The final
decisions made by the group are recorded in a separate status
report from the subgroup.
Wednesday, November 14, 1990
============================
List of participants
Steve Benford, University of Nottingham, Nottingham, United Kingdom
NG72RD (Chairman of the group)
Michael Durkin, Bell Atlantic, One Parkway, 9B, Philadelphia, Pa
19102, U S A.
Ank Hoang-van, France Telecom Cnet, 38/40 General Leclerc 92131
Issy Les Moulineaux, France
Michael Kuna, Herrenhausstrasse 10, D-1197 Berlin, Germany
Hiromiki Moriyama, NTT-PC Com, 3-23-11 Nisahi-shinbashi, Minato-ku,
Tokyo 105, Japan
Jacob Palme, Skeppargatan 73, S-115 30 Stockholm, Sweden
Jean Walravens, Alcatel Bell Telephone, Francis Wellesplein 1, B-
2018 Antwerpen, Belgium
Ulrich Zysset, Swiss Ptt/KS 3, Viktoriastrasse 21, 3030 Berne,
Switzerland
List of contributions
TD 4019: Meeting report from the GC subgroup in the previous
VII/Q.18 meeting in Munich.
TD 4020: Draft recommendation F.gc, version 3 (output of the Munich
meeting)
TD 4021: Draft recommendation X.gc, version 3 (output of the Munich
meeting)
TD 4022: GC issues and requirements, version 3 (output of the
Munich meeting)
TD 4097 Asynchronous Group Communication, liaison letter from SG I.
This letter has two appendices:
1. Draft recommendation F.agc, version 4
2. Functional specification for a typical computerized
conferencing application
D-210: Draft recommendation X.gc, version 4 (from Sweden)
D-211: Draft recommendation F.gc, version 4 (from Sweden)
D-269: Comments on the standardization of Group Communication (from
NTT, Japan)
D-300: Group Communication Information Model and Abstract Service
(from UK)
D-308: Direction for Group Communication (from UK)
MH-300: Different Group Communication Implementations (from Jacob
Palme, Sweden)
MH-301: Contribution on Draft Recommendation F.gc/X.gc (from
Michael Kuna, Germany)
GC-1: Why Attribute Carriers (from Jacob Palme, Sweden)
Planning of work during this meeting
1. Identify output and timetable for this study period
(Input paper D-308)
2. Relation to other work (Input paper 4097)
3a. Technical issues, information model (Input papers
D-210, D-211, D-300, GC-1)
3b. Technical issues, architecture (Input papers D-269,
MH-300, MH-301)
4. Issues reflecting on the MTS (restriction on distribution)
5. Identify what we need for the next meeting
Resolution of different requirements on the GC work
We noted that there are two different and possibly conflicting
views on the output wanted from the group communication work:
a. That we produce a general-purpose group communication model
and framework, which can form as the basis for different group
communication applications. This general model and framework should
not be restricted to modelling group communication as part of MHS.
b. That we produce, if possible within the present study
period, a recommendation/ standard for the interconnection of
computer conferencing system, which has a close relation to MHS.
We made a tentative decision to resolve this problem by planning to
produce three documents before the end of the present study period:
Part A: Service specifications and user functionality
(corresponding to the F.gc document)
Part B: A general framework document. This part can contain:
> A general information model
> A general architecture model
> A general management model
> A general description of user operations
Part C: Computer conferencing. This part can contain:
> How to apply the models in document A on computer
conferencing
> User operations in computer conferencing
> The specific model, architecture and protocol for
computer conferencing
Planning of future work during the present study period
Our goals (as seen at this stage of the subgroup meeting) would
then be to produce, during the present study period, Part B to CD
and CCITT draft recommendation status, Part A and C to CD and CCITT
recommendation status. The reason why part B would not go to DIS
status is that we expect that the 1992 CCITT recommendation will be
restricted in scope and functionality, and that ISO will want to
extend the scope and functionality together with CCITT in the next
study period. (See the status report for the final goals agreed at
the end of the subgroup meeting.)
Discussion of other work
We noted that work on synchronous group communication is presently
being done in SG I. We accepted that our results in part C
(computer conferencing) will be mainly aimed at asynchronous group
communication. We decided to write a liaison letter to SG I
presenting the above plans and asking for their approval. We also
decided to ask SG I for liaison from the present work on
synchronous group communication.
First pass at discussion of information model
We discussed the information model, mainly as presented in the
input papers D-210, D-211, D-300 and GC-1, noting the similarities
and differences in view on the information model.
Thursday, November 15
=====================
Future plans
Carl-Uno Manros visited us and said that there is no requirement
that we must be ready with a standard within the present CCITT
study period, but that he does require us to decide, before the end
of this meeting, whether we plan to have something ready for
approval as a CCITT recommendation within the present study period.
We decided to postpone a decision on this until Knut Smaaland can
join our group next week.
Restricted domain
We decided to write a letter to the Q.18 plenary, asking the
plenary to transfer responsibility for the function "restricted
domain" from us to the general enhancements subgroup. Jacob Palme
will draft a letter.
What kind of standards should we produce
We had a long discussion on what kind of standards we are to
produce. One alternative would be to produce the standards document
in three pieces:
A. A general definition of a group communication information
model, general architectural model and abstract service
specification.
B. A definition of computer conferencing, its abstract service
specification and how it can be realized using the general model
produced under A. above.
C. A realization of the general model produced under A., as it
can be used for computer conferencing, using partly existing
services like MTS, DS and DFR.
Another alternative would be to only produce the document B and C
as listed above, with direct specification of how B can be realized
using C.
A third alternative would be to specify A, B and C, but to define
the mappings not only from B to A and from A to C, but also between
A and C.
We made the tentative decision to try to develop this, but to be
prepared to skip the A. model if it is found to difficult or
unsuitable.
Plans for work during the present meeting
We decided to plan our work during the present meeting as follows:
Thursday afternoon: Computer conferencing model.
Friday morning: General GC model and mapping of the computer
conferencing model on it.
Monday: Summary of work during the previous week and work on the
realization using (wholly or partly) MTS, DS and DFR.
Tuesday: Concluding work, editing.
Computer conferencing model
Operations:
Role: Member
Subscription-request/Unsubscription-request (on an activity, a
conversation or a conversational branch).
Find-activities
Find-subscribed-activites
Find-contributions (includes finding contributions which are
unread, which are replies, directly or indirectly, to another
contribution etc.)
Fetch-contribution (in order to read it, print it, file it, filter
it etc.)
Re-submit a contribution (not necessarily self-written, to another
activity)
Add/remove keyword from a contribution
Find-members of an activity
Lookup information on another participant
Submit contribution
Reply to all recipients of a previous contribution
Reply to only the author of a previous contribution
Write a contribution obsoleting a previous contribution
Delete a contribution
Moderator operations
Pre-moderation:
Find-submission
Fetch-submission
Accept/reject submission (whether or how to notify the submitter is
FFS)
Re-route submission (to another activty)
Post-moderation:
Remove or reroute contribution (may include automatic removal or
rerouting of the conversational branch started by the contribution)
(Note that removal does not mean physical removal of the
contribution text itself, since the contribution may still be
available e.g. in other activities or to its author)
Owner/General manager operations
Set access controls.
Decide which entities or roles are allowed to copy, reroute or
remove contributions from an activity.
Create activity and sub-activity.
Delete activity (This may not imply physical removal of the
contributions in the activity, since they may be available as
contributions in other activities and to their writers).
Modify-activity (Some, but not all, attributes which can be
modified are expiration time, access controls, description, name,
aliases, keywords, rules, encryption policy, suspension status).
Add/remove members from activities.
Add/remove owners from activities.
Register and deregister users.
Notification handling
At least he following notifications may be needed:
Notification of acceptance and rejection of submissions to pre-
moderated activities.
Notification that you have become a member of an activity.
Delivery notifications to the conference and to its members.
Receipt notification.
Issues for further study in the above operations list:
Notifications and their use
Naming scheme
Handling of anonymous or pseudonymous contributions
How to announce new activities to potential members
Filtering
Setting keywords on activities
Friday, November 16
===================
On Friday we discussed the general group communication model. Steve
Benford presented his model. The general opinion was that we should
develop such a model, but that such development was a long term
task, and that we would in parallel develop a computer conferencing
abstract service definition and implementation based on MHS.
We also decided to produce liaison letters to SG I (regarding
future work on the F document) and to Q.20/ISO SC21/WG 4 on use of
the directory for group communication. (Later in the meeting we
decided not to produce any liaison to the Directory Group yet,
since our work on how to use the DS is not complete enough to
present to them.)
Monday, November 19
===================
On Monday, we discussed the Computer Conferencing Information
Model, Abstract Service definition and Architecture. The results of
this discussion can be found in our working paper, X.gc version 5,
part 3. Important issues during the discussions on Monday were to
what extent Computer Conferencing is to rely on the existence of a
globally interconnected Directory System and which underlying
services are best used for communication between GCSA-s.
We then decided to produce the following output documents from this
meeting:
Document Who will prepare a draft
-------- ------------------------
X.gc version 5 Jacob Palme with input from
Steve Benford
GC subgroup notes Jacob Palme
Liaison letter to SG I Jacob Palme
Restricted Domain proposal Jacob Palme
Timetable and status report Steve Benford
We then made the following table of documents which we would like
to see for the next Q.18 meeting:
Document Who is willing to work on this
-------- ------------------------------
Abstract service for
computer conferencing Jacob Palme, Steve Benford and
including ASN.1 encoding Michael Kuna
Distributed architecture Jacob Palme and Michael Kuna
for GC
General GC Information Model Steve Benford, Michael Durkin and
Jacob Palme
Computer Conferencing Steve Benford, Michael Durkin
Information Model and Jacob Palme
We decided to radically change the text in X.gc version 4 to show
how computer conferencing operations and architecture can be
derived in a top-down fashion from the computer conferencing
abstract service definition. Since we did not have time to finalize
this work during the present meeting, we will not copy the old text
of X.gc into the output working document, even though parts of the
ideas in this document will have to be handled in the final X.gc
document.
Tuesday, November 20
====================
Tuesday morning was spent on the general information model. We
especially discussed whether links are objects themselves or only
relations between objects.
On Tuesday afternoon, we went through a paper with functional
requirements on group communication coming from the the EIES
development group in New Jersey. We checked their requirements
against our requirements, and added proposals for new requirements
where needed.
------------------------------Alf.Hansen@pilot.cs.wisc.edu (Alf Hansen) (11/30/90)
Jacob,
The most probable reason why it is not working, is that you are
using a (very) old address: mhsnews@vax.runit.unit.uninett
I enclose an updated list of addresses (including the address of
mhsnews) that has recently been published on the various distribution lists.
Best regards,
Alf H
------------------------------------------------------------
Overview of available communication tools for
MHS - discussions
------------------------------------------------------------
IETF-osi-x400:
The IETF OSI X.400 working group is chartered to identify and provide
solutions for problems encountered when introducing and operating
X.400 in a dual protocol internet. The WG mailing list is
an open list for discussions about X.400 in the Internet.
Send articles to:
ietf-osi-x400@cs.wisc.edu
For list maintenance (add/delete/change), send messages to:
ietf-osi-x400-request@cs.wisc.edu
------------------------------------------------------------------------
IFIP-Gtwy:
The IFIP-Gtwy list is for the IFIP 6.5 Task Group on Gateways, which
is concerned with gateways and interworking between X.400 and
non-X.400 MHS environments and between 1984 and 1988 X.400 conformant
systems. Participation is open to anyone with something to
contribute.
This list is also available via USENET as the moderated group
comp.protocols.iso.x400.gateway. Mailing list messages and USENET
group postings flow in both directions. USENET postings are subject
to pre-screening. If your site gets a USENET feed, you may prefer to
read the news group rather than become a member of the mailing list.
For those with FTP access across the Internet, the archives are
maintained on host ICS.UCI.EDU in directory internet/ifip-gtwy/;
files can be accessed via ANONYMOUS FTP.
Send articles to:
ifip-gtwy@ics.uci.edu
(or, on USENET, post to comp.protocols.iso.x400.gateway)
For list maintenance (add/delete/change), send messages to:
ifip-gtwy-request@ics.uci.edu
------------------------------------------------------------------------
MHSnews:
The MHSnews list discusses different aspects of the CCITT X.400 (MHS)
message handling protocols and gateways to these protocols.
This list is also available on USENET as the moderated group
comp.protocols.iso.x400. Mailing list messages and USENET group
postings flow in both directions. USENET postings are subject to
pre-screening. If your site gets a USENET feed, you may prefer to
read the news group rather than become a member of the mailing list.
For efficiency reasons, there are two halves to the MHSNews list that
exchange messages: a "North American" half, and a "European" half.
Contributors and subscribers to and MHSNews should use the net
addresses nearest to them.
For those with FTP access across the Internet, the archives are
maintained on host ICS.UCI.EDU in directory internet/mhsnews/; files
can be accessed via ANONYMOUS FTP.
Contributions To MHSNews From Europe:
mhsnews@uninett.no
c=no; admd= ; prmd=uninett; o=uninett; s=mhsnews;
Requests To Be Added/Deleted/Changed In The European Distribution List:
mhsnews-request@uninett.no
c=no; admd= ; prmd=uninett; o=uninett; s=mhsnews-request;
Contributions To MHSNews From North America:
mhsnews@ics.uci.edu
(or, on USENET, post to comp.protocols.iso.x400)
Requests To Be Added/Deleted/Changed In the North American
Distribution List:
mhsnews-request@ics.uci.edu
------------------------------------------------------------------------
RARE-WG1:
This distribution-list is a forum for members of RARE WG1 (on MHS).
One WG1 representative and one vice-representative should be
nominated from each RARE-member body. If a wider distribution is
wanted, each body is free to create and maintain local
re-distribution lists.
Countries and organizations in the process of establishing formal
RARE membership may be represented in WG1 as "observers".
In certain cases, experts are invited to participate in WG1
with the status of "invited experts".
The RARE secretariat, CEC, iCPMU and the RARE MHS Project Team
are also members.
Send articles to:
c=CH; admd=ARCOM; prmd=SWITCH; o=SWITCH; ou=VERW; s=RARE-WG1;
RARE-WG1@verw.switch.ch
To become a member:
Contact your local RARE contact-person.
Updates/Modifications should be sent to the chairman of WG1:
c=CH; admd=ARCOM; prmd=SWITCH; o=SWITCH; ou=VERW; s=EPPENBERGER;
eppenberger@verw.switch.ch
------------------------------------------------------------------------
RD-MHS-Managers:
This distribution list is used by managers of national R&D MHS
services to solve day-to-day problems in the operation of the
global R&D MHS Service based on X.400, and its gateways to other
mail services.
Each R&D MHS management entity should have an address where the
responsible persons can be reached, e.g. s=PRMD-manager;...
This address should be the entry in the central list.
Send articles to:
c=no; admd= ; prmd=uninett; o=rare; s=RD-MHS-managers;
RD-MHS-Managers@rare.no
To Become A Member:
Contact your local manager.
New countries/management entities should contact:
c=no; admd= ; prmd=uninett; o=rare; s=mhs-project-team;
mhs-project-team@rare.no
--------------------------------------------------------------------
AH/90.10.22/
--------------------------------------------------------------------