🚀 go-pugleaf

From: Group communication subgroup at the Oslo meeting

Title: Some central issues in group communication work
=======================================================

Date: October 1992

1.	Abstract

This document presents a few of the most controversial
issues in the work for developing group communication
standards. We would like to have guidance from the plenary
on these issues.

2.	Table of contents

3.	Introduction to the Computer conferencing model

4.	Copying of contributions

5.	Copy-and-forward versus master-copy distribution of
information

Issue 1: Is it OK that both these service types (copy-and-
forward and master-copy) are to be provided?

6.	Class 1 and 2 service

Issue 2: Should we develop a single standard with options
for class 1 and 2 (method b above) or two separate standards
documents describing class 1 and class 2 (method a above).

Use of other services

Issue 3: Which service or services, MTS, DS, ROS or DFR,
should be used for the SA-SA-protocol?

Issue 4: Which service or services, MTS, DS, ROS or DFR,
should be used for the UA-SA-protocol?

3.	Introduction to the Computer conferencing model
--------------------------------------------------------------

The presentation below is based on the conventional
architecture with one User Agents (UA) handling the
communication with one user, and with the UA-s connected to
a Service. This service internally consists of several
Service Agents (SA). There is thus one UA-SA protocol
(corresponding to P3/P7 in X.400) and one SA-SA protocol
(corresponding to P1 in X.400).

Most of our present work is done on the computer
conferencing (CC) application of group communication (GC).

Participants: The users of the CC application.

Contributions: The informational messages exchanged by the
participants.

Group activity: A set of participants, called members of
the group activity, which exchange contributions within the
group activity. This corresponds to what in existing
software systems is called "Computer conference",
"Newsgroup" or "Bulletin board".

4.	Copying of contributions
--------------------------------------------------------------

One of the most important operations in computer
conferencing is when the user instructs his UA to retrieve
contributions belonging to a specific activity. This can be
handled in two ways:

Copying of the activity to SA-s: Every SA, which has a
UA representing a member of an activity, stores the
contributions in local storage for this SA. This means that
when a UA requests contributions, they can be delivered
directly from the store of this SA. The SA will normally not
have to connect to other SA-s in order to deliver
contributions.

A distribution system is then, of course, needed to ensure
that new contributions are distributed to the SA-s who have
copies of the activity.

Retrieval from another SA: The contributions within an
activity are fetched from another activity in another SA
when the users request them. A user request will thus
usually result in a SA-SA retrieval operation.

There is general agreement in the group communication
subgroup that the main method of providing contributions is
to be done using the method which above is called "Copying
of the activity to SA-s", but that some support for the
method called "Retrieval from another SA" is also necessary,
for example when an SA only stores the latest contributions
within an activity and a member wants to retrieve older
contributions.

5.	Copy-and-forward versus master-copy distribution
	of information
--------------------------------------------------------------

Since we agree that the contributions belonging to an
activity are to be distributed to the SA-s representing all
the members of that activity, it is important to define the
distribution method.

Two distribution methods have been discussed, one called
Copy-and-forward and one called Master copy
distribution.

With the master copy method, there is one master copy of
each activity in one particular SA. All changes to the
activity, like the submission of a new contribution, is made
to this master SA. There is then a distribution method to
distribute the contribution from the master SA to the other
participating SA-s.

With the copy-and-forward method, there is no master copy of
an activity. A participant can submit a contribution to any
service agent holding a copy of the activity. The new
contribution is then copied from this SA to neighbouring SA-
s so that the contribution will eventually appear in all
copies of the activity in all SA-s handling this activity.

The copy-and-forward method is best suited to public
activities with a large number of participants, while the
master copy method is best suited to smaller closed
activities in which stronger access controls are needed.

The opinion in the group communication subgroup is that
support for both methods is desirable. We are discussing to
have two classes of computer conferencing, class 1 which is
mainly based on the copy-and-forward method, and class 2
which is mainly based on the master-copy method.

--------------------------------------------------------------
! Issue 1: Is it OK that both these service types (copy-and- !
! forward and master-copy) are to be provided?               !
--------------------------------------------------------------

6.	Class 1 and 2 service
--------------------------------------------------------------

As described above, we are planning to develop standards for
two classes of CC services, class 1 and class 2.

Class 1 uses the copy-and-forward method, and is mainly
suited to large, public group activities.

Class 2 uses the master-copy method, and is mainly suited to
smaller, closed group activities.

We hope to let the choice between class 1 and class 2 be per
activity, and that the same service agents should support
both class 1 and class 2. However, some service agents may
support only class 1 or only class 2.

These two classes will have much in common. Most of the
protocol will be very similar or identical in both classes.
Class 2 will however contain more features than class 1. For
example, with class 1 each service agent stores the lists of
the subscribers to the activity in that service agent, and
no central list of all the members in this activity
everywhere is available, while in the class 1 service, the
master copy SA may store a list of all the participants of
the activity everywhere.

We could then develop a standard in two ways:

(a)	Develop two separate standards, one for the class 1 and
one for the class 2 service. Many features and protocol
units will then be identical in both standards.

(b)	Develop a single standards document for both class 1
and class 2, where features which are particular to only one
of the classes is marked as such in the document.

The advantage with (a) is that the standards documents,
especial the class 1 document, will be simpler to read and
understand. Some experts also were of the opinion that
solution (b) would give difficulties in handling the updates
of links.

The advantage with (b) is that duplication is avoided and
the risk of unnecessary discrepancies between the class 1
and class 2 service is avoided.

With both alternative (a) and (b), we will have to discuss
how to provide interaction between class 1 and class 2
services.

----------------------------------------------------------------
! Issue 2: Should we develop a single standard with options    !
! for class 1 and 2 (method b above) or two separate standards !
! documents describing class 1 and class 2 (method a above).   !
----------------------------------------------------------------

Use of other services
-----------------------------------------------------

Communication between SA-s, and between a UA and a SA, can
be done using existing protocols. Four alternatives have
been discussed:

(a)	Use of the MTS. Operations between two SA-s, or between
a UA and an SA, are then forwarded as a new content type via
the MTS.

(b)	The directory service, which could for example be used
to store and exchange information about attributes of group
activities, like member lists, access control constraints
etc.

(c)	Direct ROS-based access between SA-s might be used for
example when one SA needs to retrieve information available
in another SA.

(d)	DFR might be used, in which the storage of information
in each SA is handled by a DFR store, and other SA-s access
this using the DFR client-server protocol.

The advantage with using method (a), the MTS, is that this
is the major existing service for message transmission, and
also that this methods makes compatibility with conventional
MHS messaging easier to provide.

The advantage with methods (b) and (d) is that it is better
to use existing services than duplicating features of them
in the new service.

A disadvantage with method (a) is that it is more difficult
to provide immediate replies to user queries while the user
is waiting.

There is general agreement in the group communication
subgroup that the main tool for communication between SA-s
is to be method (a) above, the use of MTS. We have however
not agree on whether also some communication between SA-s
might be done using method (b), (c) or (d) above.

For the protocol between UA and SA, the majority opinion in
the group communication subgroup is to use method (a),
direct ROS-based connections, but some members of the
subgroup prefer the use of MTS also for this communication.

------------------------------------------------------------
! Issue 3: Which service or services, MTS, DS, ROS or DFR, !
! should be used for the SA-SA-protocol?                   !
------------------------------------------------------------

------------------------------------------------------------
! Issue 4: Which service or services, MTS, DS, ROS or DFR, !
! should be used for the UA-SA-protocol?                   !
------------------------------------------------------------


To: ISO/IEC JTC 1/SC 18/WG 4, CCITT VII/Q.18 and I/Q.15

From: Group communication subgroup at the Oslo meeting

Title: Notes from the experts meeting on Asynchronous
Group Communication in Oslo, October 1992
=======================================================

Date: October 1992

1.	Caution
--------------------------------------------------------------

Caution: These notes documents our discussions in mostly
chronological order. This means that all which is written
here may not agree with our final agreements.

2.	Table of contents
--------------------------------------------------------------

1.	Caution
2.	Table of contents
3.	List of participants
4.	Addresses of participants
5.	Input papers
6.	Planing of work during the meeting
7.	User requirements
8.	Master copy and non-master copy group activity handling
9.	Protocol between service agents
10.	Name "news distribution"
11.	Naming of contributions
12.	Follow-up to
13.	Author information in contribution
14.	Link objects
15.	Size indication in heading
16.	Body of contributions
17.	Activity naming
18.	Moderation of activities
19.	Creation and re-organisation of activities
20.	Other activity attributes
21.	Two standards or one
22.	Naming of participants
23.	Moderation of activities
24.	Subscription service
25.	Administration of activities
26.	Contribution storage
27.	Presentation of new activities
28.	Distribution of contributions
29.	Loop control
30.	Use of MTS for SA-SA protocol
31.	Use of the DFR
32.	Co-ordination with IPM
33.	Geographical and organisational distribution controls
34.	Two standards or one?
35.	Contributors
36.	Prospective member
37.	Frozen activities
38.	Cancelling contributions  from one of two activities
39.	ASN.1 encoding of computer conferencing objects
40.	Removal of links
41.	Burning of objects in the middle of conversations
42.	Rewriting of X.acc
43.	Future meetings

3.	List of participants
--------------------------------------------------------------

Hiromi Murakami, Toshihiko Yamakami, Jacob Palme, Pierrick
Morand and (part of the time) Harald T. Alvestrand.

4.	Addresses of participants
--------------------------------------------------------------

Hiromi
Murakami
5-7-20-309 Shinjuku
Shinjuku-ku
Tokyo
Japan
Phone: +81-3-3225-9901
Fax: +81-3-32259889
e-mail: hiromi@nttpro.ntt.jp

Toshihiko Yamakami
Take 1-2356 Yokosuka
Kanagawa 338-03
Japan
Phone:+81-468-59-3781
Fax: +81-468-59-3729
e-mail: yam@nttmhs.ntt.jp

Jacob Palme
Skeppargatan 73
S-115 30 Stockholm
Sweden
Phone:+46-8-664 77 48
Fax: +46-8-703 90 25
e-mail: jpalme@kom.dafa.se

Pierrick Morand
SEPT
42, Rue des Coutmes
BP 6243
14066 Caen Cedex
France
Phone:+33-31 75 91 79
Fax: +33-31 73 56 26

Harald Tveit Alvestrand
Sintef Delab,
7034 Trondheim
Norway
Phone:+47-759 70 94
Fax: +47-753 25 86
e-mail: harald.alestrand@delab.sintef.no

5.	Input papers
--------------------------------------------------------------

MH-14: NTT: A proposal for News Distribution service and model on MHS.

MH-27: NTT: A proposal for extending a parameter, dl-expansion-prohibited

MH-33: Nottingham GC Experts meeting: Proposed disposition of comments,
new work item proposal on Computer Supported Voting and Polling as a
Group Communication Task

MH-34: Nottingham GC experts meeting: Proposed disposition of comments,
new work item proposal on Asynchronous Distributed Document Production

MH-35: Nottingham GC Experts meeting: Proposed work plan for ISO and CCITT
Group Communication

MH-36: Nottingham GC Experts meeting: Group communication and hypermedia
framework

MH-37: Nottingham GC Experts meeting: Notes from the experts meeting on
Asynchronous Group Communication in Nottingham, June 1992

MH-38: Nottingham GC Experts meeting: CCITT co-operation and the
acceptance of new work items

MH-39: Nottingham GC Experts meeting: Synchronous and asynchronous joint
editing

MH-44: Jacob Palme: Some questions on the Computer Conferencing model

MH-45: GC Editor as instructed by the Nottingham meeting:
Asynchronous Computer Conferencing Working document, X.acc version 10

MH-51: Japan ISO member: Japanese comment on electronic news
distribution protocol in GC

MH-52: Secretariat WG4: Provisional Meeting Announcement for
GC Experts Meeting in New Jersey in December

MH-64: GC Editor as instructed by the Nottingham meeting:
Group Communication Working Document X.agc version 10

MH-65: Jacob Palme: Comparison of Computer Conferencing and
News Distribution Services

MH-66: Jacob Palme: Proposed liaison on ISO CD 10956

MH-67: ISO/TC 46/SC 9 Secretariat: ISO CD 10956 Bibliographic References -
Electronic Documents or Parts Thereof

MH-68: Murray Turoff and Jacob Palme:  Group Communications
Experts Meeting: Dec. 14-18, 1992

MH-69: Jacob Palme: Standards for Asynchronous Group Communication

MH-71: ISO/IEC JTC 1/SC 18/WG 3 and CCITT SG VIII Q27: Work Item on
Asynchronous distributed document production

6.	Planing of work during the meeting
--------------------------------------------------------------

Plans for work during the meeting:

A)	Architectural model for distributed operations.

B)	News distribution: MH-14, MH-51, MH-64.

C)	Computer Conferencing: MH-27, MH-37, MH-44, MH-45,  MH-69.

D)	Bibliographic references: MH-67, MH-71.

E)	New work items: MH-33, MH-34, MH-38, MH-39.

F) 	Group Communication: MH-64.

G)	Future work plan: MH-35, MH-52, MH-68.

7.	User requirements
--------------------------------------------------------------

We began by discussing user requirements. We agreed on the
following modified version of an excerpt from MH-69 as a
tentative first definition of the basic user requirements:

>	Members of groups can submit contributions to a group
using the name of the group as recipient, they need thus not
list all the members of the group when they submit their
contributions (a). Members can in some systems also remove
their messages after submission (b). The same contribution
can be sent to more than one group, recipients will still
not have to read contributions more than once even though
they receive it through several different groups (c).

>	Users can subscribe to groups (d) and unsubscribe (e)
from them, except that for closed groups the moderator must
approve new members.

>	Members can retrieve contributions that have been
submitted to the groups they subscribe to (f). It is
possible to ask for only the new contributions, unseen for
one particular user (g), but it is also possible to retrieve
old contributions (h). A new member of a group may be
allowed to retrieve contributions written before the member
began subscribing to the group (i).

>	Users can read contributions in a structured order. By
this is meant that contributions which relate to each other
are read at the same time. By related contributions is meant
contributions sent to the same group (j), and, within a
group, contributions belonging to the same conversation (k).
A conversation is a number of contributions related to each
other by direct or indirect reply links. Users also often
have facilities to skip part of the discussions, such as the
discussions in a certain conversation (l), or at a certain
time within a certain group (m).

>	Each group may have one or more moderators who can
control which contributions are allowed, either through pre-
moderation (n), where the moderator approves contributions
before they are distributed, or post-moderation (o), where
the moderator can remove unacceptable contributions.
Moderators can also move contributions from group to group
(p), start new groups or subgroups when needed (q), and
control membership for closed groups (r). Groups can also be
unmoderated.

8.	Master copy and non-master copy group activity handling
--------------------------------------------------------------

We noted that there are two modes of handling distributed
group activities. The two modes are:

>	Master copy method: There is one master copy of each
activity in one particular service agent. All new
contributions must be sent first to this master copy server.
That server will then ensure that the contribution is copied
to all other service agents which hold shadow copies of this
group activity.

>	Non-master copy method: There is no master copy. A
submitter of a contribution submits it to the nearest server
which holds a copy of that group activity. That server then
forwards it to adjacent servers, so that it will eventually
be copied to every server who has a copy of the activity.
None of the servers is subordinate to any other server.

Comparing these methods, we noted that each has its
advantages and disadvantages:

Advantages with Master copy method:

The master copy method makes it easier to have high degree
of control of where an activity is copied and who is allowed
to participate in which way. It is also easier to handle
cases where contradictory update operations arrive from
different users.

Advantages with Non-master copy method:

The non-master copy method can give faster distribution
since a message does not have to go to the master server
first and then back again to the recipients. It is more
fault-tolerant, since it does not rely on any particular
server. If one server is done, adjacent servers can easy
reconfigure to get contributions bypassing that server. It
is also possible to have multiple paths between the server
from the beginning, so that no reconfiguration at all is
needed if one server goes down. This method avoids the cost
of handling central control of distribution and will thus be
more efficient from this viewpoint.

We agreed that since both methods have their advantages and
disadvantages, both methods should be supported in future
group communication standards.

9.	Protocol between service agents
--------------------------------------------------------------

The main communication between service agents is the
distribution of contributions. This distribution can be
handled in two ways:

>	The distribution method: The server which gets a new
contribution sends them to adjacent servers using MTS.

>	The request method: A server which wants new
contributions sends request operations to adjacent servers
for new contributions.

Both methods should be supported. Probably, most
distribution of new contributions is done using the
distribution method. The request method is however necessary
when a new copy of an activity wants to download old
contributions, written before this copy was started. It is
also useful when technical problems like running out of disk
storage causes contributions to be deleted -P they can then
be downloaded again from adjacent servers.

10.	Name "news distribution"
--------------------------------------------------------------

We agreed  that "news distribution" is not an ideal name for
the service proposed in MH-51. We discussed other
alternative names such as "non-master-copy computer
conferencing" or "computer conferencing class 1" but did not
make any final decision on the name of this service. In the
rest of these minutes, the term "Computer conferencing class
1" is going  to be used for "news distribution" and
"Computer conferencing class 2" is going to used for the
more advanced service described in the present X.acc
document.

11.	Naming of contributions
--------------------------------------------------------------

We agreed that contributions should be named in ways which
is compatible with IPM identfiers. However:

>	Contribution names should always be globally unique.

>	To reduce the risk of different contributions getting
the same identifier, the same O/R-name should not be reused
for different purposes at different times, unless the new
and  the old owner of the O/R-name agree on not creating
identical IPM Identifiers.

>	If an O/R-name changes, the occurrences of that O/R-
name in already created IPM Identifiers should not be
changed.

12.	Follow-up to
--------------------------------------------------------------

We agreed that this heading field should be available for
both class 1 and class 2 computer conferencing.

13.	Author information in contribution
--------------------------------------------------------------

We agreed that such information should be optional fields,
but that with growing use of directory systems in the future
such fields may not anymore be necessary.

14.	Link objects
--------------------------------------------------------------

Our tentative decision is not to have explicit link objects
in class 1 conferencing, but this has to be discussed more
before final decision is taken.

15.	Size indication in heading
--------------------------------------------------------------

Our tentative decision is to allow this as an optional
heading field.

16.	Body of contributions
--------------------------------------------------------------

We agreed that the bodies of contributions should be fully
IPM compatible, i.e. the same body parts as in IPM should be
allowed. A contribution can thus have several body parts of
different type, just as in IPM. A body part type for
including another contribution within a contribution should
also be allowed, similar to the forwarded IPM body part type
in IPM.

17.	Activity naming
--------------------------------------------------------------

We had a long discussion about how to name computer
conferencing activities. We want them to have globally
unique names. Possible ways of getting this is by using
object identifiers or distinguished directory names. We did
not know whether there is a registration authority scheme
for providing globally unique distinguished directory names.

This is an issue where we need further guidance.

There is also a need to have names of computer conferences
which are not subordinate to a particular country. Can the
directory tree be extended with branches below the root for
international organisations which are not subordinate to any
country?

18.	Moderation of activities
--------------------------------------------------------------

We agreed with the need for activities being pre-moderated
or unmoderated. Temporal-moderated also might be a useful
temporary attribute of an activity.

19.	Creation and re-organisation of activities
--------------------------------------------------------------

We had a long discussion on the services for the creation of
new activities, and for re-organisation of activities such
as merging and splitting of activities. We agreed with the
proposal to allow a temporary attribute "to be split at
<date>" on an activity which is to be split, in order to
inform members of the forthcoming split.

After a split, the old activity might be kept as read-only.
Some of us also wanted a facility for an organiser of the
new activity to move old contributions to one or the other
of the new split versions of the activity, but we did not
agree on whether this service should only be available in
the class 2 service or also in the class 1 service.

It is a local policy decision whether the management of a
service agent wants to restrict who may create new
activities within their service agent.

A temporary period "call for open" during which users can
try out a new activity before making a final decision on
whether to create it permanently or not also seemed like a
useful service.

20.	Other activity attributes
--------------------------------------------------------------

We agreed on the new attributes "language", "importance",
"organisations" and "transitive-information" but felt that
these attributes were useful both in class 1 and class 2
computer conferencing.

21.	Two standards or one
--------------------------------------------------------------

We discussed whether there should be two separate standards,
one for class 1 conferencing ("news distribution") and one
for class 2 conferencing.

Arguments for two standards were that these services and
especially the distribution protocols were said to be so
different that it will anyway have to be two different
standards.

Arguments for one standard is that there will also be many
similarities, and that implementation costs will be lower if
the same implementation, with minor changes, can be used for
both services, and that one should try to avoid having two
different standards for similar services as much as
possible.

No agreement was reached.

Guidance from the plenary would be appreciated.

22.	Naming of participants
--------------------------------------------------------------

We agreed that the free-form-name should be used to give a
human-friendly name, but not to store roles, temporal roles
etc.

We agreed that participants should be named by O/R-names,
where the Distinguished Name component should be optional
just as in MHS. Every participant should have an MHS O/R-
address as component of its O/R-name.

23.	Moderation of activities
--------------------------------------------------------------

We had a long discussion of moderation of activities. The
conclusions were:

A contributor always submits his contribution to the
activity, not to the moderator, even if the activity is pre-
moderated.

When a contribution to a pre-moderated activity arrives at
an SA, that SA will forward the contribution through MTS to
a particular OR-address given in the description of the
activity. This particular OR-address will cause the message
to be forwarded to one of or all of the moderators. This
could be arranged for example by letting the OR-address lead
to a distribution list with the moderators as members.

One might also store the personal OR-address of the
moderator directly in the description of the SA. The problem
with this is that whenever moderators changes, this
information has to be updated in all copies of the
description of the activity in all SA-s. It might therefore
be better not to store the personal OR-address of the
moderator in this field.

It is also advantageous for a moderator if contributions are
delivered to him in a way which clearly indicates which
activity they are destined for, so that the moderator will
not confuse his own personal mail with contributions to the
activities which he is a moderator of.

24.	Subscription service
--------------------------------------------------------------

We agreed that the SA of the user should employ a simple
news control feature, which does not eliminate duplicates of
the same contribution sent to several activities or cases
where the user reads contributions in non-linear order. More
advanced news control is handled by the UA of the user, not
by the SA. At least for class 1 computer conferencing.

In class 1 conferencing, there is no central list of all the
subscribers to an activity. In class 2 conferencing, all
subscriptions must go via the master server, and this master
server can then contain a list of the subscribers, but
whether such a list is mandatory for the class 2 service is
FFS.

25.	Administration of activities
--------------------------------------------------------------

We had a long discussion about administration of activities.
Who is allowed to create new activities, who is allowed to
change the attributes of an activity, for example to change
its mode from unmoderated to pre-moderated or to split it or
to delete it? We did not reach an agreement. In the class 1
service, it is difficult to have central control of this,
but on the other hand it is also dangerous to allow any user
such wide powers. FFS.

26.	Contribution storage
--------------------------------------------------------------

We agreed that normally the contributions of activities
should be copied to all service agents where there are
subscribers to the activity. In some cases, the
contributions are also copied to intermediate service agents
for forwarding contributions, especially in the class 1
conferencing service.

In other cases, for example activities with very large and
space-consuming contributions, like those containing object
programs, could be stored in fewer places. In such a case,
when a user asks his service agent for such an object, his
service agent must be capable of retrieving it from the
service agent which holds it in storage. Normally, however,
contributions are available in the local service agents of
its members, so that they can retrieve them without
communication between service agents.

27.	Presentation of new activities
--------------------------------------------------------------

When a new activity is created, information about the
activity can be distributed in four ways:

(a)	Putting a description of the new activity in the
directory system, so that users can search in the directory
systems for activities on particular topics using the DS
search facilities.

(b)	Putting  a description of the new activity in a special
kind of contribution, which is contributed to other
activities whose members might be interested in the new
activity. For example, special activities for the
presentation of other activities may exist.

(c)	Sending the description of the new activity as MHS mail
messages to people who might be interested in joining the
new activity.

(d)	Sending the description of the new activity as MHS mail
messages to those service agents, where participants can
subscribe to the activity.

Method (d) should always be available. Optionally, methods
(a) to (c) may also be used.

28.	Distribution of contributions
--------------------------------------------------------------

We discussed different methods of distribution of
contributions to all the service agents handling the
activity. We agreed that this distribution should be
reasonably fast, some of us felt that the longest delay from
contribution to reception for non-pre-moderated activities
should normally be less than 2 hours, others felt that a
total delay of 24 hours was acceptable. (Such delay times
should go into the CCITT F version of the standard, and are
not to be included in the ISO version of the standard.)

To reduce the time for distribution, distribution should
normally be initiated by the sending SA, since the sending
SA knows when a new contribution has arrived and can send it
out immediately.

Also, to reduce the time for distribution, too deep nesting
of SA-s getting contributions from other service agents via
the MTS should be avoided.

29.	Loop control
--------------------------------------------------------------

There are three main methods of loop and duplication
control:

(a)	The service agent stores the ID-s of the contribution
which has passed through it, and rejects the same
contribution if it arrives again.

(b)	The history of the service agents which a contribution
has passed is stored in the envelope or heading of the
contribution.

(c)	The nesting of the SA-s is arranged so that no loops
can exist.

We agreed that method (a) should always be used, that method
(b) should preferably also be used. On method (c), there was
some disagreement, since some of us felt that this method
can cause large inefficiencies in cases where there are a
very large number of SA-s participating in an activity.

30.	Use of MTS for SA-SA protocol
--------------------------------------------------------------

The main communication path for sending information between
SA-s will be MTS. However, it should optionally also be
possible to use the DS to distribute information about
activities, like description, access control information,
membership lists etc.. A typical example of use of the DS is
that the creator of a new activity stores information in the
DS about this activity, and that a participant looking for
this activity will later search for it in the DS.

31.	Use of the DFR
--------------------------------------------------------------

We decided to delegate to Jacob Palme to write a paper
specifying what uses we may have of the DFR for group
communication, phrased as a number of questions to DFR
experts on what functionality they can provide to group
communication.

32.	Co-ordination with IPM
--------------------------------------------------------------

We made a tentative decision that instead of a posted-on
link/attribute to indicate which activity a contribution has
been submitted to, the primaryrecipient, copyrecipient and
blindcopyrecipient links/attributes already defined in IPM
should be used.

This also influence clause 7.3.1 of X.acc version 10.

This means that the name of an activity should have the
format of an OR-descriptor in IPM. In this O/R-descriptor,
the O/R-address will be empty  for class 1 conferencing,
since class 1 activities do not have any O/R-address.
However, the Directory Name component of the O/R-name in the
O/R-descriptor should include a globally unique
Distinguished Name of this group communication activity.

In general, we agreed that we should try to get a format for
contributions which is compatible with the P22 IPM format
(but with additional heading extensions). We should
investigate to what extent this is functionally and
technically realisable. In particular, it should be possible
for an ordinary MHS UA to participate in group
communication. The group communication activity will then
look like a distribution list to this ordinary MHS UA.

The format of new notifications needed for the group
communication application will of course not be IPM
compatible.

33.	Geographical and organisational distribution controls
--------------------------------------------------------------

Usenet News has a feature to limit the distribution of a
contribution to those members of an activity which are
within a certain company, within a certain town or country
etc.

The proposal to add a similar facility to MHS distribution
lists has earlier been rejected by WG4M and SC VII at the
Ottawa meeting in 1991. However, the proposal which was
rejected at that meeting was to add this feature to the P1
protocol. If, instead, this feature as in MH-51 is added in
the content of the message, it may be more acceptable.

34.	Two standards or one?
--------------------------------------------------------------

Should we develop class 1 conferencing and class 2
conferencing as two separate standards (with mostly similar
content) or as one standard with options for class 1 or
class 2? This is a controversial issue on which we do not
have a shared opinion yet.

35.	Contributors
--------------------------------------------------------------

In X.acc version 10, clause 7.2.6.1 contributors which can
submit contribution to an activity but not read in that
activity is presented. We should give examples on how this
is used, and we should also specify whether the contributor
of such a contribution can read his own contribution (he
can!) and whether he can read replies to his own
contribution (yes if the writer of the reply so wishes, no
if the writer of the reply so wishes).

36.	Prospective member
--------------------------------------------------------------

In X.acc version 10, clause 7.2.6.2, prospective members are
described. We should clarify that there can be different
kinds of prospective members, like prospective regular
member, prospective editor, prospective observer etc.

37.	Frozen activities
--------------------------------------------------------------

X.acc version 10, clause 7.2.3.1 talks about frozen objects.
When an activity is frozen, also the submission of new
contributions to that activity is stopped. The word "in
modification" should be more clearly defined.

38.	Cancelling contributions  from one of two activities
--------------------------------------------------------------

We discussed the case where a contribution (e.g.
contribution 17) has been submitted to two different
activities (A and B), and where the author of the
contribution a few minutes later wants to remove the
contribution from one of the activities (e.g. A), but keep
it in the other activity (B).

One way to do this proposed was to use an un-link or remove-
link operation. This operation is distributed in the same
way as ordinary contributions, to all copies of the
activities A and B in all service agents. In the copies of
the activity A, this operation tells this activity to remove
the contribution. In the copies of the activity B, this
operation tells the members of B, that this contribution is
now a B-only contribution, and not any more a contribution
to both A and B.

We did not make any final agreement on whether this is the
correct way of performing this operation. In  the user
interface, this operation may be a command like "cancel
contribution 17 in conference A" or "remove the recipient
conference A from contribution 17". However, we do not
standardise the user interface, we only standardise the
internal technical functionality.

39.	ASN.1 encoding of computer conferencing objects
--------------------------------------------------------------

The soft typing, as described in MH-44, should be used.
However, we should look t MH-74 for the new notation in the
latest version of ASN.1 which should be used in new
standards.

40.	Removal of links
--------------------------------------------------------------

The procedure for removal of links described in section 3.
of MH-44 was felt to be too complicated.

41.	Burning of objects in the middle of conversations
--------------------------------------------------------------

(section 6 of MH-44). We discussed the alternative of
keeping some remnants (skeleton) of the burned object,
enough so that the conversation is not broken.

42.	Rewriting of X.acc
--------------------------------------------------------------

It was generally felt that X.acc is too difficult to
understand, and that if this method of handling group
communication is to accepted by the standards community, it
must be rewritten to clarify the essential concepts in a way
which is easier to understand.

Especially, the following should be explained in X.acc:

(1)	How to make shadow copies of activities

(2)	How to make shadow copies of contributions

(3)	How to make shadow copies of links

(4)	How to manage inter-service-agent links (links
referring to objects whose master copies are in different
service agents)

(5)	How to name (give identifiers) to links, especially
inter-service-agent links

43.	Future meetings
--------------------------------------------------------------

Since Japan, France and Norway cannot come to the planned
extra experts meeting on group communication in New Jersey,
we decided to recommend to cancel this meeting. Instead, we
will try to persuade those group communication experts which
were not present in this meeting, to come to the regular WG
4 meetings. However, we felt that 2,5 days time for real
technical work during 5 day WG 4 meetings is too short.
Therefore, we ask WG4 to plan its future meetings to begin
on a Wednesday instead of a Monday. Then, those subgroups
which need more time can start their meetings on the Monday
two days before the official start of the WG4 meeting. We
asked Japan if this procedure could be used during the Tokyo
meeting in February 1993.

44.	Combinations of classes of service and types of
activities
--------------------------------------------------------------

We discussed which such combinations should be supported as
follows:


				Class 1 service	Class 2 service
				(copy-and-forward (Master-shadow
				distribution)	distribution)

Open (public)
conferences, which
anyone can join		Yes			Yes

Closed conferences,	To some extent	Yes
with restrictions		but there will
on who may			be limits on
participate			which kind of
				access controls
				are possible

45.	Approved and non-approved contributions
--------------------------------------------------------------

In all activities where there is some access control on the
right to contribute (either automatic or via pre-moderation)
there is a need to distinguish between the activities to
which a contribution has been sent, and the activities in
which the contribution has been accepted by the access
control or moderator.

One solution to this would be to have the following links:

Primary recipient, CopyRecipient, BlindCopyRecipient: Set by
the originator of the contribution, indicating the
activities to which the contribution was submitted.

AcceptedTo: Set by the moderator or the access control
mechanism when the contribution was accepted into the
activity.

When such a message is sent to an ordinary MHS/IPM UA, that
UA will not be able to see the "AcceptedTo" extended heading
field, and will thus not be provided with the information in
this field. A group communication UA will however be able to
receive and handle this subfield.

46.	Garbage collection
--------------------------------------------------------------

We discussed the garbage collection which most computer
conferencing systems employ. What happens if a link gets
removed before the text it refers to is removed, or the
opposite, what happens if a text is removed before a link is
removed?

If a link is removed before the text it refers to, users may
be given misleading information. This should thus be
avoided. The opposite, removal of the text when the link is
not removed, is not so dangerous. For example, if a user
says "give me the contribution to which this is a reply" it
is perfectly reasonable if the system replies "sorry, that
contribution is not kept any longer".

However, these kinds of things should not be part of the
proper standard. They may be put into a technical report,
which is given as an appendix to the standard.

47.	Retrieval of notifications
--------------------------------------------------------------

We discussed whether it should be possible to retrieve
notifications. For example, should it be possible to find
out who has removed a contribution from an activity. This is
a useful service, but we have not decided whether to include
it in class 1 conferencing or only have it in class 2
conferencing.

48.	Afternoon work
--------------------------------------------------------------

During Thursday afternoon, we are going to go through input
documents MH-36, MH-51 and MH-69. This work will not be
minuted, since papers for the final plenary must be
submitted for copying on Thursday at 1:00 P.M.

49.	Extension of DL-expansion prohibited
--------------------------------------------------------------

We discussed the input paper MH-27, which proposes a change
in the DL-expansion-prohibited P1 attribute.

Our opinion was not to accept this proposal. We are however
planning to provide similar services in a new content type
for Group Communication.


To: ISO/IEC JTC 1/SC 18/WG 4, CCITT VII/Q.18 and I/Q.15

From: Group communication subgroup at the Oslo meeting

Title: Notes from the Thursday afternoon experts meeting on
Asynchronous Group Communication in Oslo, October 1992
=============================================================
Date: October 1992

1.	Caution
--------------------------------------------------------------

Caution: These are the notes from the discussion on Thursday
afternoon in the group communication subgroup. These notes
have not been seen and checked by the members of the
subgroup, so they should only be regarded as my personal
impressions of what we said.

2.	User requirements
--------------------------------------------------------------

We noted that Murray Turoff had promised, at the Nottingham
meeting, to produce a split of the user requirements
document (F.agc) into user requirements on general group
communication and on computer conferencing. We are looking
forward to his forthcoming user requirements documents.

3.	UA-SA and SA-SA communication
--------------------------------------------------------------

We are planning to mainly use MTS (also, optionally DS for
activity descriptions) for communication between service
agents. Communication between UA and SA will mainly be ROS-
based, but a MTS-based alternative may also be defined.

4.	Distribution list management
--------------------------------------------------------------

We discussed whether a standard for distribution list
management is needed, but could not agree on this.

5.	Stay with WG 4 SPWM
--------------------------------------------------------------

It was our opinion that group communication standards
development should continue under the umbrella of WG 4 SPWM,
VII/Q.18 and I/Q.15.

6.	Master copies of contributions?
--------------------------------------------------------------

We noted that if we define the standard so that
contributions cannot be changed, then no master and shadow
copies of contributions are needed.

7.	Editors
--------------------------------------------------------------

We noted that maybe Steve Benford will not be able to
participate in our meetings in the future. In that case, new
editors must be appointed for the parts which Steve
currently is editor for.

8.	News service paper
--------------------------------------------------------------

We made a thorough review of MH-51 and made a number of
comments on it.

Concerns were voiced by some members of the group in two
areas:

>	The contribution format should to a larger extent be
based on P22.

>	The class 1 and class 2 services should be merged into
one document.


To: ISO/IEC JTC 1/SC 18/WG 4, CCITT VII/Q.18 and I/Q.15

From: Jacob Palme

Title: Reorganisation of the Group Communication working
documents
==========================================================
Date: October 1992

Based on the discussions at the group communication meeting
in Oslo in October 1992, I propose the following
reorganisation of the group communication working documents:

Part 1: Group communication general data model.

This will be mostly the same as the present group
communication model paper.

Part 2: Computer conferencing data model and abstract
services.

This part will describe the services of both class 1 and
class 2 conferencing.

Part 3: Classes of the computer conferencing service.

This part will define which parts of the conferencing
service belongs to different classes, in particular the
class 1 and class 2 service.

Part 4: UA-SA protocols.

This part will define a ROS-based version of the UA-SA
protocols.

Part 5: SA-SA agent protocols.

This part will define the operations between SA-s in a way
which is not mapped on any existing underlying service.

Part 6: Realisation of the SA-SA protocols mapped on the
MTS.

This part will define a realisation of the SA-SA protocol on
top of MTS.

Part 7: Realisation of part of the SA-SA protocols mapped on
the DS.

This part will define a realisation of part of the SA-SA
protocols (handling the descriptions of group activities)
based on the DS.

Part 8: Realisation of the UA-SA protocols based on the DFR.

This part will define a realisation of whole or part of the
UA-SA protocols based on the DFR access protocol.

Part 9: Realisation of the UA-SA protocols based on the MS.

This part will define a realisation of whole or part of the
UA-SA protocols based on the MHS UA-MS protocol (=P7).


To: ISO/IEC JTC 1/SC 18/WG 4, CCITT VII/Q.18 and I/Q.15

From: Group communication subgroup at the Oslo meeting

Title: Cancellation of the New Jersey meeting
============================================================

Date: October 1992

The meeting, which has earlier been planned, with group
communication experts in New Jersey in December 1992, is
cancelled. The next meeting of Group Communication experts
will instead be in Tokyo in February. That meeting may
however start two days earlier than the official WG 4
meeting in order to have more time for work.