Group Communication Editor:
Jacob Palme, Stockholm University
Skeppargatan 73, S-11530 Stockholm, Sweden	%: +46-8-664 77 48
Fax: +46-8-703 90 25
E-mail: jpalme@dsv.su.se	

  ISO/IEC  10021-acc  Working paper
  Group Communication
  INFORMATION TECHNOLOGY —
  Message HANDLING Systems
  Part n: Asynchronous COMPUTER CONFERENCING

  CCITT Working paper X.acc

Date:	August 1993
SOURCE:	Group Communication editor, Jacob Palme, as instructed by the Cambridge meeting, July 1993, of the collaborative team of CCITT Study Group 7 question 14 and ISO/IEC JTC 1/SC 18/WG 4 SPWM
Health warning!
This is a working document only. Much can be changed before it becomes a Draft recommendation/Committe Document. Do not base any implementations on this document!!!
Status of this document
This document is the fourteenth version of the Asynchronous Computer Conferencing Working Document X.acc | ISO/IEC 10021-acc. A number of versions of this document will be produced before the final draft recommendation. It has not been reviewed by the SG VII Rapporteurs Groups.
This document is the current working paper, edited by the editor as instructed by the Group Communication experts meeting in Cambridge, July 1993.
Differences as compared with version 13 are marked with a line in the left margin as for this paragraph (except trivial changes in terminology). Such a line is also used for new sections which are very uncontroversial. 
Important changes or new sections in version 14 are marked with double lines in the margin as for this paragraph.
 Sometimes, underlining is also used to show more exactly which words have been changed.
Strike-through (as in this paragraph) is sometimes used to indicate text which the editor has deleted since the previous version.
The ASN.1 in this paper is at present a mixture of 1988 and 1992 ASN.1 conventions. They must be entirely converted to 1992 ASN.1 conventions before making this into a CD.
The present document contains a large number of FFS items. In order to aid future work, I have tried to put priorities on such items. The priority classes are:
Prio 1: Very important issues which should be resolved rapidly
Prio 2: Relatively important issues
Prio 3: Other issues which should be resolved at meetings
Prio 4: Other issues which might be resolved by the editor alone
Stockholm August 30, 1993

Jacob Palme, Group Communication Editor
Contents
Temporary note: Annexes are text intended for the final version of X.acc | ISO/IEC 10021-acc. Appendices are text only included in the working document, and which will not go into the final version of X.acc | ISO/IEC 10021-acc in this format.
Introduction	xii
1.	Overview	1
2.	Relation to other recommendations	1
3.	References	1
4.	Definitions	1
5.	Abbreviations	2
6.	Conventions	3
6.1	Drawing conventions	3
7.	Asynchronous Computer Conferencing Overview and Model	3
7.1	Scope and Limits of Scope	3
7.2	Overview of the Asynchronous Computer Conferencing Data Model	4
7.2.1	Basic Concepts of Asynchronous Computer Conferencing	4
7.2.2	Links	5
7.2.2.1	Links between group activities and contributions	5
7.2.2.2	Links between group activities and members	5
7.2.2.3	Links between contributions	6
7.2.2.4	Links between group activities	7
7.2.3	Grouping contributions and participants	7
7.2.3.1	Group activities	7
7.2.3.2	Conversation	8
7.2.3.3	This clause was removed in Tokyo 1993	8
7.2.4	Other items than links	8
7.2.4.1	Contribution	8
7.2.4.2	Submission	8
7.2.4.3	Notification	8
7.2.5	Entities	9
7.2.5.1	Entity	9
7.2.5.2	Participant	9
7.2.5.3	Conference Service Manager	9
7.2.5.4	Workspace	9
7.2.5.5	External participant	9
7.2.6	Links between participants and group activities	9
7.2.6.1	Member	9
7.2.6.2	Prospective member	10
7.2.6.3	Regular member (Regular Group Activity Member	10
7.2.6.4	Moderator	10
7.2.6.5	Administrator	10
7.2.6.6	This clause was removed in Tokyo 1993	11
7.2.6.7	Owner	11
7.2.6.8	Observer	11
7.2.6.9	Contributor	11
7.3	Fuller examples of use of the Information Model	11
7.3.1	Information structure	11
7.3.2	Examples of membership links	12
7.3.3	Submission procedure	13
7.3.4	News control	14
7.4	User functions	16
7.4.1	Specialized set of functions	16
7.4.2	This chapter has been removed in X.acc version 13	17
8.	Asynchronous Computer Conferencing Objects and Attributes	17
8.1	Imported attributes	17
8.2	Matching rules	17
8.3	Attribute macro and table	17
8.4	ACC object hierarchy (inheritance of attributes)	19
8.5	ACC object (common attributes for all ACC objects)	22
8.5.1	Notation	22
8.5.2	ACC Object class	22
8.5.3	Class-type	23
8.5.4	Name (of all kinds of computer conferencing objects)	23
8.5.4.1	Activity names	24
8.5.4.2	Participant names	24
8.5.4.3	Contribution identifiers	24
8.5.4.4	Link identifiers	25
8.5.5	Alias names	25
8.5.6	Originator-name	25
8.5.7	Object-descriptor	25
8.5.8	Free-form-name	26
8.5.9	Original-creation-time	26
8.5.10	Creation-time	26
8.5.11	This clause was deleted in version 13, since owner is a link, not an attribute	26
8.5.12	Return-path	27
8.5.13	Dummy	27
8.5.14	Last-modification-time	27
8.5.15	Locked-by	27
8.5.16	Last-modifier	28
8.5.17	Status	28
8.5.18	Retention-period	28
8.5.19	Master-copy-controlled	29
8.5.20	Retrieval-status	29
8.5.21	Master-SA	29
8.5.22	Non-modifiable	29
8.5.23	Distribution-area-list	30
8.5.24	Keywords	30
8.5.25	Authorizing-users	30
8.6	Group activity (subclass to ACC Object)	31
8.6.1	Group-activity object class	31
8.6.2	Activity-description	31
8.6.3	Moderation-policies	32
8.6.4	Anonymous-allowed	32
8.6.5	Anonymous-required	32
8.6.6	Hidden-members-allowed	33
8.6.7	Member-list-available	33
8.6.8	Activity-task	33
8.6.9	Non-members-can-submit	34
8.6.10	Allowed-content-types	34
8.6.11	Size-limitation-on-contributions	34
8.6.12	Size-limitation-on-replies	34
8.6.13	Depth-limitation-on-contributions	34
8.6.14	Expiry-time	35
8.6.15	Languages	35
8.6.16	Importance	35
8.6.17	Organizations	35
8.6.18	This clause was removed at the Tokyo meeting 1993	36
8.6.19	Default-expiry-time	36
8.6.20	Master-copy-distributed	36
8.6.21	Master-copy-membership-handling	36
8.6.22	MHS-submission-allowed	36
8.6.23	MHS-distribution-allowed	37
8.7	This section was removed at the Tokyo 1993 meeting	37
8.8	Participant (subclass to ACC Object)	37
8.8.1	Participant object class	37
8.8.2	Participant-description	38
8.8.3	Participant-preferred-delivery-method	38
8.8.4	Last-present	39
8.8.5	Participant-statistics	39
8.9	Item (subclass to ACC Object)	40
8.10	Contribution (subclass to ACC Item)	40
8.10.1	Subject	41
8.10.2	Summary	41
8.10.3	Lines	42
8.10.4	Expiry-time	42
8.10.5	Reply-time	42
8.10.6	Importance	42
8.10.7	Sensitivity	42
8.10.8	Auto-forwarded	43
8.10.9	Request-for-acceptance-notification	43
8.10.10	Suppression-of-rejection-notification	43
8.10.11	Languages	43
8.10.12	Incomplete-copy	44
8.10.13	Auto-submission-indication	44
8.10.14	Priority	44
8.10.15	Digest	44
8.10.16	Body	45
8.10.17	MTS Envelope fields	45
8.11	Modification of contributions	45
8.12	ACC Link (subclass to ACC Item)	45
8.12.1	Link object class	45
8.12.2	Link-from	46
8.12.3	Link-to	46
8.12.4	Submittor-report-request	46
8.12.5	Link-type	47
8.12.6	List of link types	47
8.12.7	Tickets	49
8.12.8	Distribution of links	50
8.12.9	The seen relation (subclass to ACC Link)	50
8.13	Links from participants to group activities (subclasses to ACC Link)	50
8.13.1	Roles	50
8.13.1.1	This clause was removed at the Tokyo 1993 meeting	52
8.13.1.2	This clause was removed at the Tokyo 1993 meeting	52
8.13.1.3	Role-preferred-delivery-method	52
8.13.1.4	Role-wants-all	52
8.13.1.5	Role-last-present	52
8.13.1.6	Role-statistics	53
8.13.2	Owner, Administrator, Member, Observer, Contributor	53
8.13.3	Moderator (subclass to role)	54
8.13.4	Sees-rejected-submissions	54
8.14	Links from contributions, notifications and other items to group activities (subclasses to ACC Link)	54
8.14.1	Primary-recipient, Copy-recipient and Blind-copy-recipient	54
8.14.2	Reply-recipient	55
8.14.3	Followup-to	55
8.14.4	Submission-link (subclass to ACC Link)	56
8.14.5	Acceptance-decision (subclass to ACC Link)	56
8.14.5.1	Submission-reference	57
8.14.5.2	Decision-taken	57
8.14.5.3	Withdrawn-by-submittor	57
8.14.5.4	Withdrawn-by-originator	57
8.14.6	Accepted-contribution (subclass to acceptance-decision)	58
8.14.7	Rejected-submission (subclass to acceptance-decision)	58
8.14.7.1	Rejection-reason	58
8.15	Links between contributions	59
8.15.1	Replied-to, Obsoleted, Related	59
8.16	Links between activities	59
8.16.1	Super-activity, Open-for-member, Open-for-observer, Closed-for	59
8.17	ACC Notifications (subclass to ACC Item)	60
8.17.1	ACC Notification common attributes	60
8.17.1.1	Notification-type	60
8.17.2.	Apply-to	60
8.17.3.	Confirmation-requested	61
8.17.4.	Immediate-confirmation	61
8.17.5.	Triggered-by	61
8.17.6.	MHS notifications	63
8.17.7.	Attribute-adder (subclass to ACC Notification)	63
8.17.8.	Attribute-subtractor (subclass to ACC Notification)	64
8.17.9.	Object-inhibitor (subclass to ACC Notification)	64
8.17.10.	Object-Burner (subclass to ACC Notification)	64
8.17.11.	Presence-report (subclass to ACC Notification)	65
8.17.12.	Subscription-change (subclass to Acc-notification)	65
8.17.12.1	Member-names-to-add	66
8.17.12.2	Membership-action	66
8.17.12.3	Membership-type	66
8.17.12.4	Number-of-old-items-wanted	67
8.17.13.	Membership-decision (acceptance, rejection, notification)	67
8.17.13.1	Member-name	67
8.17.13.2	Membership-action-result	68
8.17.13.3	Membership-decision-reason	68
8.17.13.4	Role-given	68
8.17.13.5	Number-of-old-items-provided	68
8.17.14.	Memberlist-finder	69
8.17.14.1	Only-one-member	69
8.17.14.2	Maximum-number-of-members	69
8.17.14.3	Role-restrictor	69
8.17.14.4	Role-attribute-restrictor	70
8.17.15.	Memberlist-report	70
8.17.15.1	Membership-list	70
8.17.15.2	Not-all-members-listed	71
8.17.16.	Memberlist-error	71
8.17.17.	Update-distribution	71
8.17.17.1	Update-distribution-action	72
8.17.18.	Routing-report-request	72
8.17.18.1	Activity-restriction	72
8.17.18.2	Server-restriction	73
8.17.18.3	Announcement-request	73
8.17.19.	Routing-report	73
8.17.19.1	Routing-report	73
8.17.19.2	Incomplete	74
8.17.20.	Confirmation	74
8.17.20.1	Confirmation-report	75
8.17.21.	Activity-announcement (Subclass to both Activity and Item)	75
8.17.21.1	Announced-activity	76
8.17.21.2	Previous-announcement	76
8.17.21.3	Moderators	76
8.17.21.4	Managers	76
8.17.22.	Free-input-links	77
9.	Asynchronous Conferencing Abstract User Functions	77
9.1	Ports and Functions	77
9.1.1	Member port	78
9.1.2	Moderator port	83
9.1.3	Conference Management Port	84
9.1.4	This clause, numbered 9.6 in X.acc | ISO/IEC 10021-acc version 11 was removed in June 1993	85
9.1.5	More about notification handling	85
9.1.6	Issues for further study:	85
10.	Realisation of the Abstract User Functions	86
10.1	Distributed realisation of the computer conferencing service	86
10.1.1	Partitioning	86
10.1.2	Operations on master-copy-controlled activities	87
10.1.2.1	Operational procedure	87
10.1.2.2	Navigation	87
10.1.2.3	Execution	87
10.1.2.4	Access control on master-copy-controlled activities	88
10.1.3	Operations on non-master-copy-controlled activities	89
10.1.3.1	Access control on non-master-copy-controlled activities	89
10.1.4	Communication between ACC-SA-s	89
10.1.5	Distribution of new contributions	91
10.1.5.1	Distribution for a master-copy-distributed activity	91
10.1.5.2	Distribution for an activity which is not master-copy-distributed	92
10.1.6	Varying real implementations	92
10.1.7	Co-working with MHS	94
10.1.8	Purging	94
10.1.9	For further study	94
10.2	Co-location of IPM and Asynchronous Conferencing	95
10.3	Realisation of the Abstract User Functions	95
10.3.1	Member port abstract user functions	95
10.3.1.1	Find-activities (realisation)	95
10.3.1.2	Find-subscribed-activities (realisation)	96
10.3.1.3	Describe-activity (realisation)	96
10.3.1.4	Subscription-request (realisation)	96
10.3.1.5	List-news (realisation)	96
10.3.1.6	Find-contributions (realisation)	97
10.3.1.7	Find-notifications (realisation)	97
10.3.1.8	Read-item (realisation)	97
10.3.1.9	Mark (realisation)	97
10.3.1.10	Submit-item (realisation)	97
10.3.1.11	Withdraw-submission (realisation)	98
10.3.1.12	Personal-reply (realisation)	98
10.3.1.13	Add-attribute (realisation)	98
10.3.1.14	Remove-attribute (realisation)	98
10.3.1.15	Add-link (realisation)	98
10.3.1.16	Remove-link (realisation)	99
10.3.1.17	Delete-object (realisation)	99
10.3.1.18	Find-members (realisation)	99
10.3.1.19	Describe-participant (realisation)	99
10.3.1.20	Describe-member (realisation)	99
10.3.1.21	Modify-profile (realisation)	100
10.3.1.22	Download news (realisation)	100
10.3.2	Moderator port abstract user functions	100
10.3.2.1	Find-submissions (realisation)	100
10.3.2.2	Accept and reject (realisation)	100
10.3.2.3	Collapse (realisation)	100
10.3.2.4	Create-group-activity (realisation)	101
10.3.2.5	Announce-group-activity (realisation)	101
10.3.2.6	Suspend-group-activity (realisation)	101
10.3.2.7	Delete-group-activity (realisation)	101
10.3.2.8	Add-member and remove-member (realisation)	101
10.3.2.9	Reject-subscription-request (realisation)	101
10.3.3	Administrator port abstract user functions	102
10.3.3.1	Modify-group-activity (realisation)	102
10.3.3.2	Register-participant and unregister-participant (realisation)	102
10.3.3.3	Routing (realisation)	102
11.	Asynchronous Computer Conferencing Access Protocol (UA-SA protocol, ACCAP)	102
11.1	Abstract-bind and Abstract-unbind Operations	103
11.1.1	Abstract-bind-argument	103
11.1.2	Abstract-bind-result	104
11.1.3	Abstract-bind-errors	104
11.1.4	Abstract-unbind-operation	104
11.2	Abstract-operations	104
11.2.1	Common data-types used in abstract-operations	104
11.2.1.1	Range	105
11.2.1.2	Filters	105
11.2.1.3	Selector	105
11.2.1.4	LinkChoice	105
11.2.1.5	Entry-information-selection	106
11.2.1.6	Entry-information	106
11.2.2	Format for forwarding items	107
11.2.3	Use of IPM heading fields	107
11.2.4	Additional heading extensions	108
11.2.5	Summary of abstract operations	109
11.2.6	ACC-Summarize abstract-operation	109
11.2.7	ACC-List abstract-operation	110
11.2.8	ACC-Fetch abstract-operation	110
11.2.9	ACC-Register abstract-operation	111
11.2.9.1	ACC-Register-argument	112
11.2.10	Alert abstract-operation	112
11.2.11	ACC-Modify abstract-operation	112
11.2.12	Acc-submit abstract-operation	112
11.2.12.1	Acc-submit-argument	113
11.2.12.2	Acc-submit-result	113
11.2.12.3	Acc-submit Abstract-errors	114
11.3	Abstract-errors	114
11.3.1	Error precedence	114
11.3.2	Attribute-error	115
11.3.3	Fetch-restriction-error	115
11.3.4	Invalid-parameters-error	116
11.3.5	Range-error	116
11.3.6	Security-error	117
11.3.7	Sequence-number-error	117
11.3.8	Service-error	117
11.3.9	Content-specific-error	118
11.3.10	ACC-Register-error	118
11.3.11	Activity-not-known-error	119
12.	Asynchronous Computer Conferencing Server Protocol (SA-SA-protocol, ACCSP)	119
12.1	General operating procedures of an ACC-SA	119
12.1.1	How an ACC-SA can get new objects	119
12.1.2	Redistribution of incoming object	119
12.1.3	Reciept of objects from MHS distribution list	120
12.2	Special actions triggered by certain objects	120
12.2.1	Digests, special actions	120
12.2.2	Links. special actions	120
12.2.3	Accepted-contribution, special actions	121
12.2.4	Rejected-submission, special actions	121
12.2.5	Submissions to pre-moderated activities, special actions	121
12.2.6	Attribute-adder and attribute-subtractor, special actions	121
12.2.7	Object-inhibitor and object-burner, special actions	121
12.2.8	Presence-report, special actions	122
12.2.9	Subscription-change, special actions	122
12.2.10	Memberlist-finder, special actions	122
12.2.11	Update-distribution, special actions	122
12.2.12	Routing-report-request, special actions	122
12.2.13	Objects arriving in non-logical order and dummy objects	122
12.3	Forward-item operation	123
12.3.1	Transmission of objects between ACC-SA-s	124
12.3.2	Transmission-modes	124
12.3.3	Transmission in use-MTS mode	124
12.3.4	Transmission in use-ROSE mode	125
12.3.5	Transmission in use-DS mode	125
12.3.6	Transmission in use-DFR mode	126
12.4	ACC-Control-protocol	126
Annex A: ASN.1 for the Computer Conferencing Abstract Service	129
Annex B: Mapping of ACC operations on the Message Handling System (MHS)	129
Annex C:	Mapping of ACC operations on the Directory System (DS)	129
Annex D:	Mapping of ACC operations on the Document Filing and Retrieval System (DFR)	129
Annex E:	Mapping between the ACC service and Internet mail/Netnews	130
Annex F:	Glossary of Terms	132
Annex G:	Security Overview	133
G.1	Introduction	133
G.2	Vulnerabilities	133
G.3	Vulnerability analysis	133
G.4	Security services	133
Annex H:	Index	134
Introduction
This recommendations is one of a set of Recommendations for Message Handling. The entire set provides a comprehensive specification for Message Handling comprising any number of cooperating open-systems....
...to be supplied...
...Postal Services).
This recommendation defines the overall system and services of Asynchronous Computer Conferencing.

1.	Overview
FFS should contain information about how to find what you are looking for in this recommendation. (Priority = 4, June 1993)
2.	Relation to other recommendations
This Recommendation defines the overall system and service of Asynchronous Computer Conferencing.
Asynchronous Computer Conferencing is an application of Asynchronous Group Communication. Asynchronous Group Communication is described in Recommendation F.agc/X.agc.
Asynchronous Computer Conferencing is related to, and can use the services of, Message Handling Systems (as defined in Recommendation X.400) and Directory Systems (as defined in Recommendation X.500), and Document Filing and Retrieval Services (as defined in IS 10166).
The general model for the Group Communication System and Services is defined in documents F.agc/X.agc.
3.	References
FFS to be supplied. (Priority = 4, June 1993)
4.	Definitions
4.1	Common definitions for MHS
For a list of the common definitions for MHS refer to CCITT Rec. X.402 | ISO/IEC 10021-2.
4.2	Computer conferencing definitions
	The act when a moderator in a pre-moderated activity accepts contributions to it.	
	See Group Communication Activity.	
	The act of making a contribution available to the members of an activity. Compare with the term submit.	
	An item containing a body of text contributed by a user to the other members of an activity.	
	A set of contributions exchanged between a set of members on a common topic or task.	
	An item is an information object. Examples of items are contributions, notifications and activity presentations.	
	The ACC-SA which controls an activity which is either master-copy-controlled, master-copy-distributed or has master-copy-membership-handling.	
	Attribute indicating that there is a master copy of this object and that changes can only be made through the ACC-SA holding the master copy.	
	Attribute of an activity, indicating that distribution of objects within it can only be made via the ACC-SA holding the master copy of the activity.	
	Attribute of an activity, indicating that members can only be added via the ACC-SA hodling the master copy of the activity. This ACC-SA holds a list of all members of the activity everywhere. If member-list-available is set, this list can be made available to participants subject to access control.	
	Control of the contributions in an activity by one or more specially authorized members, called moderators. Moderation can be either pre-moderation or post-moderation (or both).	
	Specially authorized members of an activity which can control which contributions are allowed in the activity.	
	The act of contributing a contribution which obsoletes a previous contribution.	
	Control of the contributions in an activity, such that the moderators can remove contributions not suitable for the activity. Contributions are however initially distributed without waiting for the approval by the moderators.	
	Control of the contributions in an activity, such that only contributions approved by the moderators are distributed to the members of the activity.	
	The act when a moderator in a pre-moderated activity rejects contributions to it.	
	If an object B is a subclass to an object A, it has all the attributes of A plus the additonal attributes particular to B.	
	A contribution which has been submitted, but which has not yet been accepted by the moderators.	
	The act of submitting a contribution to a pre-moderated activity, which will be distributed to the members of the activities if it is accepted by the moderators.	
	The act of indicating that a participant wants to participate in a particular activity.	
	The storage of information that a participant subscribes to a particular activity.	
	By text is meant not only a message consisting of a sequence of characters, but also messages presented as pictures, sound or other means, or by a combination of different means.	
	The ACC-SA to which serves a certain user.	
	The time between the date of adding a contribution to a group activity and its removal from the activity.	
	Cooperation which does not take place in real time, information sent between participants is stored, so that one user can receive input from the other users and produce output to them at independent times. This does not preclude several participants to be active at the same time, but information between them need then not be transmitted in real time.	
	An information object with its initial set of attributes at is first submission.	
	An atomic object used to add, change or delete attributes for an information object.	
	The actions of one or more group members which result in a change to an existing shared coummincation object, and will impact upon one or more other members by (i) Result in notifications to other members (ii) Influence, regulate or control the actions of other members (iii) Determine the avilable functionality for the other members.	
	A message submitted within Asynchronous Computer Conferencing.	
	A set of messages related directly or indirectly by links such as inReplyTo, RelatedTo, Obsoletes etc.	
	A derivation rule, and the set of information objects implicitly defined by this derivation rule.	
	A set of messages related directly or indirectly to an original message by Obsoletes attributes.	
	A service for providing the distribution of information objects to a set of subscribers. Also known as News Distribution.	
	An agent in the MTS, which will redistribute incoming messages to a list of subscribers.	
	The actions of creating and deleting distribution lists, adding and removing subscribers from them. Also the process of managing a set of nested lists.	
	A named organization of a set of messages and a set of users who have read or write access to the set of messages or receive them. For example Computer Conference and Bulletin Board are specific kinds of activities.	
	Tools to enable several people to cooperate via open communication systems. See also Social Group Communication and Collaborative Group Communication.	
	A piece of information handled in group communication, such as messages or documents.	
	The transfer of a communication object from and by a designated orginator to one or more designated receivers.	
	Word added to an information object to be used in searches.	
	(of a group activity) One or more OR-names designating users or roles with special controlling rights on roles within an activity.	
	An atomic object, which has been changed by the addition, removal or change of one or more attributes.	
	A service enabling a DFRSUA to download only those information objects which are new to it.	
	See Distribution and Subscription.	
	Limiting the distribution of a contribution to recipients within a certain geographical or organizational area.	
	The time after the removal of a contribution from a group activity, during which it can be recreated using the undo facility.	
	A link between a user and an activity, giving that user the right to assume this role. Assuming this role gives the user certain privileges to perform specific functions according to defined rules and constraints.	
	Members of a group are related to the group by their participating in a common communication process. There is no need for coordination among individual members with respect to their individual actions in enaging in the group communications process.	
	Cooperation which takes place in real time, i.e. the users cooperating are at one and the same time exchanging information.	
5.	Abbreviations
	Distribution List	
	For Further Study	
	Group Communication Environment	
	Group Communication  Service	
	Group Communication Service Agent	
	Group Communication User Agent	
	Group Communication Access Protocol, the protocol between a GCUA and a GCSA	
	Computer Conferencing Service Protocol, the protocol between two ACC-SA-s	
	Computer Conferencing  Service	
	Computer Conferencing Service Agent	
	Computer Conferencing User Agent	
	Computer Conferencing Access Protocol, the protocol between an ACC-UA and an ACC-SA	
	Computer Conferencing Service Protocol, the protocol between two ACC-SA-s	
	Inter-Personal Messaging	
	Inter-Personal Messaging Service	
	Inter-Personal User Agent	
	Message Transfer Service	
	Directory System	
	Directory System User Agent	
	Directory Access Protocol, the protocol between a DUA and a DSA	
	Directory System Protocol, the protocol between two DSA-s	
	Document Filing and Retrieval Service	
	Document Filing and Retrieval User Agent	
	Document Filing and Retrieval Service Agent	
	DFR Access Protocol, The protocol between a DFRUA and a DFRSA	
	Management Responsibility Area	
6.	Conventions
...to be supplied...
This document is formatted according to the agreed format for joint CCITT/ISO/IEC documents.
6.1	
These drawing conventions are used in most of the drawings in this recommendation.

Figure %

Figure %

7.	Asynchronous Computer Conferencing 
7.1	
This section specifies an overview of, and model for, an application of Asynchronous Group Communication called Asynchronous Computer Conferencing (ACC).
Asynchronous Computer Conferencing describes a system for computer conferencing consisting of  group activities, conversations, contributions, links and participants. Asynchronous means that there is no support for ‘real-time’ communication between participants (e.g. video conferencing).
Asynchronous Computer Conferencing (ACC) is an application within the area of Message Handling Systems (MHS). Message Handling Systems are applications which enable users to exchange messages. Particular for ACC is that messages are made available to a group of users, the users who are members of a particular Group Activity. The main characteristics of a Group Activity is that it is a group of users, who exchange a set of messages relating to a particular subject area or task. The messages exchanged in Asynchronous Group Communication are called Contributions.
The terms “” “” and “” are commonly used terms to describe what in this standards is called “” or sometimes only “”.
The services described in this recommendation do not include certain advanced computer conferencing services. For example, the following services are not included:
•	.
•	.
•	.
•	.
•	Special .
•	“”, i.e. 
•	“”, i.e.  and controlled , task descriptions and requests.
7.2	Classes of service
Asynchronous Computer Conferencing, as described here, has functions which are organised into three classes, class 1, class 2 and class 3.
The facilities available for Asynchronous Group Communication in the MHS system as defined in X.411 (multi-recipient messages and distribution lists) can be seen as a class 0 of the Asynchronous Computer Conferencing service.
Each higher class contains all the functionalities in the lower classes plus additional functionalities of the higher class.
The main functionalities in each class are:
Class 0: Multi-recipient messages, distribution lists.
Class 1: Activities open to everyone, with decentralised control and no central control of membership of the activities. Activities can however be pre-moderated, by which is meant that one or several moderators of the activity control what is submitted to it. Contributions in the class 1 service are distributed by copying from server to server. MHS UA-s can participate, the activities will then appear like distribution lists to them. No list of the members of an activity is available.
Class 2: Closed activities (with restricted access) and central control of membership of activities. Lists of all the members of an activity can optionally be made available, with information for each member of when that member was last active in this activity. Class 2 uses a more powerful data model, based on the idea of objects and links.
Class 3: Anonymous participation, settable size limitations particular to certain activities and statistics on user behaviour.
7.2	Basic Concepts of the 
The three are participants, group activities and contributions.
represent people and other entities that are active users of computer conferencing.
are the messages which are exchanged in computer conferencing.
A group activity is a tool for organizing a group of participants and a set of contributions exchanged by these participants on a common . A group activity allows a number of participants, called of this group activity, to exchange contributions within the topic of the group activity. Information about contributions belonging to a group activity is stored, so that it is possible to retrieve information about the contributions which have been contributed to this group activity. In the class 1 service, all group activities are open, i.e. there is no control of whom may participate in class 1 group activities.
An asynchronous computer conferencing system can handle several group activities. A system for inter-personal messaging as defined in the X.400 series of recommendations must always be included with a computer conferencing system, in order to allow participants to send inter-personal messages to people, from whom they have received contributions.
Figure % illustrates the main concepts of asynchronous computer conferencing.

Figure %

7.2.3	Items
Items are messages which are distributed in the ACC service. Examples of item types  in class 1 are contributions, submissions, notifications and activity presentations.
7.2.4.1	
Contributions are individual items posted on group activities. The structure of contributions is based on P22 messages as defined in X.420 (see Annex B). The bodies of contrubitons contain the message to be conveyed. A contribution may be posted on more than one group activity. Contributions may be related to other contributions in various ways to generate larger information structures like conversations (see figure %).
7.2.4.2	

Figure %

A submission is an item, which has been submitted to a pre-moderated group activity, but not yet accepted. The submission is not delivered to the members of the activity until it has been accepted by a moderator. The originator submits the submission to the CCS, and the CCS delivers the submission to a moderator.The moderator sends an acceptance or a rejection notification to the submittor. If the submission is accepted, the moderator forwards it to the activity, in the IP-forwarding format (i.e. with an outer header with the moderator as originator, and an inner header with the original submittor as originator) to the activity in the same way as for a contribution originated by the moderator.
Note – The format of the MessageBodyPart (see X.420 section 7.3.8) when forwarding a submission shall not contain any values for the optional parameter delivery-envelope. MessageData can be either IPN or a computer conferencing object.
If there is more than one moderator, a submission is accepted when any of the moderators (usually the first who sees it) accepts it. The other moderators are after acceptance shown the submission as an ordinary accepted entry in the activity. Each moderator can control whether s/he is to be shown those contributions which have already been rejected by another moderator (using the sees-rejected-submissions attribute of the moderator link). Rejections are however always distributed too the ACC-UA-s of the other moderators, since this information is necessary to avoid forcing the other moderators to make new acceptance decisions. The ACC-UA of the other moderators may however not show the rejected submissions to the other moderator unless the moderator explicitly asks for this information.
The owner is allowed to accept and reject submissions, but is not shown new submissions unless the owner is also a moderator. Contributions by any of the moderators or owners are directly accepted.

A similar format is used when a contribution, originally submitted to one activity, is forwarded to other activities.
7.2.4.3	
Notifications are special kinds of messages to transfer information about group-communication events (e.g. the rejection of a contribution from a pre-moderated group activity). The structure of notifications is based on the IPM format as defined in X.420, except for those notifications which correspond to X.400 notifications, which use the format defined for such notifications in X.411 for MTS notifications and in X.420 for IP notifications.
7.2.4.4	Activity presentations
Activity presentations are items giving information about activities. This information can also be stored in directory systems, allowing participants to search for activities. Activity presentations can be submitted to other activities. Activities, which mainly contain presentations of other activities, are called presentation activities.
7.2.5	Entities
7.2.5.1	
Entities represent users and other agents who become involved in the conferencing service. Entities include human users, computer programs or organizational persons.
7.2.5.2	
An entity who has been registered to use the conferencing service is called a participant.
7.2.5.3	
A conference service manager is a participant with administrative rights over the conferencing service within a Management Responsibility Area (MRA). Such an area may comprise one or more computer conferencing servers or domains. Examples include creating and deleting group activities, registering participants and adding and removing group activity administrators and owners.
For activities without central-membership-handling, the part of the activity within each ACC-SA can have a different manager.
7.2.5.4	Workspace
Each participant has a workspace where personal information (e.g. notifications for this participant) is located. The mailbox with IPM messages to the participant can also be seen as part of this personal workspace.
7.2.5.5	
An external participant is an MHS UA of another kind than an ACC (Asynchronous Computer Conferencing) UA. IPM UA-s, but not Voice Messaging UA-s and EDI UA-s, can be external participants. External participants can participate in the computer conferencing service, but their capabilities will be restricted compared to full ACC UA-s.
7.3	Additional concepts in the class 2 data model
7.2.2	
Links are a special kind of object in the class 2 data model. Each link is used to link two other objects together. A link can be seen as having the format shown in figure %. 

Figure %

Examples of uses of links are given in the following section.
7.2.2.1	
Contributions are in the class 2 data model linked to group activities through links. The same contribution can be contributed to more than one activity, there is then one link for each activity, linking the object to the activity. These links can be used to find the contributions in an activity, or to find the activities to which a contribution has been submitted. See figure %.

Figure %

7.2.2.1	
Note the equivalence between links from contributions to activities (in the class 2 service) and IP-forwarding (in the class 1 service). Suppose that a contribution has been originated by John Bird and sent by him to Activity A, and that the contribution is then forwarde by Mary Fox to Activity B. The upper part of figure % shows how this can be represented through IP-forwarding in the class 1 service, and the lower part of figure % shows how this can be represented through link objects in the class 2 service.
This equivalence is utilized, so that the IP-forwarding format can be used when forwarding links between contributions and activities through the MTS. The format shown in the upper part of figure % is thus a representation of the data structure in the lower part of figure % when forwarding through the MTS.

Figure %
Equivalence of IP-forwarding and links
Note – The format of the MessageBodyPart (see X.420 section 7.3.8) when using the IP-forwarding format shall not contain any values for the optional parameter delivery-envelope. MessageData can be either IPN or a computer conferencing object.
7.2.2.2	
Members are linked to the group activities with links. If the same participant is a member of more than one activity, then there is one link from the participant to each activity, in which s/he is a member. Member links can be used to find which participants are members of a certain activity, or to find which activities a certain participant is a member of. See figure %.

Figure %

Membership links can be of several types, representing different roles of the member in the activity, like ordinary member, moderator, owner.
7.2.2.3	
Contributions are often related to each other. Such relations are represented by links such as related-IPMs, obsoleted-IPMs and replied-to-IPM between contributions. Comments on previous entries normally use the related-IPMs link within a group discussion context, and the replied-to-IPM for personally addressed messages. See figure %.

Figure %

7.2.2.4	
Links between activities can be used to create a hierarchy of group activities, as is shown in figure %.

Figure %

7.2.3	Grouping contributions and participants
7.2.3.1	
A group activity is a subclass of a group communication domain as defined in X.agc.
A group activity represents an exchange of information about a specific subject or task. It corresponds to the terms or as used elsewhere.
Group activities can be:
•	Open or public (any participant can make himself a member).
•	Closed or private (only the administrator or owner can add new members, but non-members can apply for membership)
•	Restricted (only a certain set of participants can make themself a member. The administrator and owner can add also other participants than this set as members). Participants who are not members, but may make themselves into members are called .
•	Protected (only the administrator and owner can add members, outsiders are not told of its existence and can not even apply for membership).
A group activity can be pre-moderated, post-moderated or un-moderated. See the description of moderator below.
The service profile of a Group activity can in the class 3 service control what kind of contributions are allowed for this activity. Examples of such controls are:
•	A limit on the size of contributions.
•	A limit on the size of replies on contributions.
•	A limit on the depth (number of levels) on conversations.
•	A limit on the body part types allowed in this activity.
7.2.3.2	
A conversation is a set of messages related directly or indirectly to each other by certain kinds of links. The exact definition of the concept of conversations, such as which link types participate in forming conversations, is a local implementation matter. The exact definition of how a conversation is formed is not defined in this standard.
7.2.4	Other items than links
Links are one kind of item. Other kinds of items are contributions, submissions and notifications, as defined in section %.
7.2.6	Links between participants and group activities
7.2.6.1	(Group Activity Member)
A link from a participant to a particular group activity is called a . The most common roles convey membership to the activity. A participant who has membership link is called a member.
Examples of types of of memberswithin a group activity in the class 2 service : regular members, owners, group activity administrators, contributors (can write but not read), moderators (can modify, remove and add contributions), observers (can read but not write) and hidden members (whose membership is not divulged to other members).
Note – Contributors typically occur for activities which accept input from outsiders, such as editorial boards or help desks.
External participants can be regular members, contributors and observers.
7.2.6.2	
A prospective member of a group activity is a participant who is allowed to make himself into a member of a group activity. A prospective member can be a prospective regular member, prospective moderator, prospective administrator etc. depending on which kind of members the prospective member can make himself into.
Prospective members can be defined by enumeration, by reference to the members of an existing domain (using the open-for-member, open-for-observer and closed-for links), or by certain attributes of the members, such as employees of a certain company or people within a certain geographical region.
7.2.6.3	Regular member (Regular Group Activity )
A regular member is a member of a group activity who reads and writes contributions. Non-members may also be given permission to access information on a group activity. In spite of this, regular membership is an important concept as it allows users to easily identify group activities of interest and find out which other participants are members of this group activity. Membership may also be necessary where charging is introduced.
7.2.6.4	(Group Activity Moderator)
A moderator is a member with controlling rights over information in a group activity. Pre-moderating involves review of submitted contributions before acceptance. Contributions are not distributed to other members than the moderators before acceptance. Section % describes the action of a moderator in accepting a submission and the format of the accepted contribution. Post-moderation involves possible removal, after acceptance, of contributions from the activity. Post-moderation also may involve re-organization of contributions. A moderator may also be able to change certain attributes in a contribution, as seen within the activity (subject to the rules for changing contributions).
Note – Contributions by moderators, administrators and owners for pre-moderated group activities are sent out directly and are not subject to any moderator-review-process.
When a moderator of a pre-moderated activity accepts a contribution, or contributes a contribution of his own, an acceptance-decision link is created between the contribution and the activity.
7.2.6.5	()
An administrator is a participant with administrative control of a group activity (e.g. the ability to add and remove members or change the group activity description and policies). 
Note – An administrator is not automatically a member.
7.2.6.7	(Group Activity Owner)
A group activity owner has all possible rights in relation to the owned activity.
An important difference between owner and moderator, is that the moderators are shown all submissions to pre-moderated activities. If the owner wants to see submissions, then a separate moderator link from the owner to the activity is needed.
An important difference between owner and administrator, is that the administrators are shown all requests for membership from applicants who are not allowed to make themselves into members. If the owner wants to see such requests, then a separate administrator link from the owner to the activity to the activity is needed.
7.2.6.8	(Group Activity Observer)
An observer is a member who can only read, not write contributions in an acitivty.
7.2.6.9	(Group Activity Contributor)
A contributor is a member who can contribute, but not read contributions in activity.
7.3	Fuller examples of use of the class 2 Information Model
This section gives more complete examples of uses of the class 2 information model, and shows how the functionality of the Asynchronous Computer Conferencing Application can be mapped on the Group Communication Information Model.
7.3.1	Information structure
Figure 7-2 shows possible structures of Group Activities and Contributions.

Figure 7-2
Structures of 
Notes: 
•	Naming links for contributions are not shown. Contributions are named with IPM Identifiers as defined in X.420.
•	Although the contributions form a network structure, the system could display them in some other form (e.g. use data stamps to show them in cronological order).
•	Each contribution must be explicitly posted on a group activity - a reply, relating contribution or obsoleting contribution will not automatically be linked to all activities of the original contribution.
7.3.2	Examples of membership links
Diagram 7-3 shows possible membership link structures for Group Activities.

Figure 7-3

Note: The Delegates link can be used to temporarilly convey some of the rights of a certain role-holder to another role-holder. This functionality is a local implementation matter and conveyance of it between SA-s is not defined in this standard, but may be defined in future extensions to the standard.
	Diagram 7-4 shows how a group of owners can be common to more than one conference:

Figure 7-4
	
7.3.4	
News control refers to the ability for the system to determine and present “new” items which have not yet been read by a participant.
Retrieval-status is stored for each participant and for each item which is destined for that person. Retrieval-status is only available to the user it applies to, and will thus to the user look like an attribute of the items, but an attribute which shows separate values for each participant.
has three values:
new	the user has not seen the item at all,
listed	the user has listed the item, but not seen its contents,
processed	the user has seen the item or decided to mark it as processed.
Note – This standard does not regulate the ways in which an implementation can internally store retrieval-status information, only how that information looks to the participant. Possible implementations are to store the retrieval-status for each participant and each item, or to store only a marker of how far the participant has listed or processed items in the activity, plus exception information of items not listed or processed in sequential order.
7.4	User functions
7.4.1	Specialized set of functions
A computer conferencing participant can search for group activities in two ways. The find-activity function searches for activities which are linked to other activities. The find-subscribed-activities can be used to find which activities a certain participant is a member of (=has a membership link to).
The describe-activity function can be used to find information about a certain group activity.
A participant can ask for membership in a group activity with the subscription-request function, and can withdraw from mebership with the unsubscribe function.
A participant kan ask for information about how many unread contributions there are in a set of group activities with the list-news function.
A participant can search for contributions using the find-contributions function, and can search for notifications with the find-notifications function.
A participant can get access to the attributes of a contribution or notification with the ACC-Fetch operation. The ACC-Fetch operation may mark the contribution as processed or listed if this is requested in a parameter to the operation. A participant can mark items as new, listed or processed with the mark function.
A participant can submit contributions with the submit-item function. A submitted contribution, which has not yet been accepted by the moderator in a pre-moderated activity, can be withdrawn by the submittor with the withdraw-submission function. The personal-reply function allows replies, only sent to the originator, on contributions.
A participant can add and remove attributes and links to information objects with the add-attribute and remove-attribute function and add-link function.
A participant can remove items from domains with the remove-item function and can delete items with the delete-item function.
A participant can retrieve lists of members of group activities with the find-members function.
A participant can find attributes for another participant with the describe-participant function, and can find information about the status of another participant's membership in a group activity with the describe-member function.
A participant can modify the personal profile of another participant with the modify-profile function.
The download-news function ca be used for bulk downloading of unseen contributions.
A moderator can find not yet accepted submissions with the find-submission function, and can then accept or reject them with the accept and the reject function.
The moderator can remove old versions of contributions which have been replaced by new versions with the collapse function.
A participant can create new group activities with the create-group-activity function and can announce activities to prospective members with the announce-group-activity function.
An owner or administrator of a group activity can add and remove membership links to an activity with the add-member and remove-member function, and can reject requests for membership with the reject-subscription-request function. The owner or administrator can also modify an existing activity with the modify-group-activity function.
The manager of a computer conferencing service can enter and remove participants with the register-participant and unregister-participant function.
7.4.2	This chapter has been removed in X.acc version 13
Reason: Since functions (chapter 9) are now implemented using more general abstract operations (chapter 10 and 11).
8.	Asynchronous Computer Conferencing Objects and Attributes
8.1	Imported attributes
Attributes, which are used, but not defined, in X.acc | ISO 10021-acc are imported from X.413 | ISO 10021-5.
8.2	
When performing search operations, attributes can be compared using the three matching rules defined in X.413 chapter 12: , , ., and .
In addition to this, an additional matching rule is introduced, with the name . This matching rule is used when comparing names of objects of the types ACCObjectName and ACCObjectDescriptor.
Two ACCObjectDescriptors are equal if their formalname components are equal, even if their free-form-name component is not identical.
Two ACCObjectNames of the activity-name or participant-name match according to ORName matching rules. Two ORNames match according to the matching rules defined in X.413, which means that they match if either the directory-name component or the ORAddress component match.
8.3	Attribute macro and table
ACC uses the ATTRIBUTE macro as defined in X.413.
ACC imports the following attributes from X.413:
Imported attribute	Single/multivalued	Usage in ACC	
AC-correlated-report-list	M	To inform managers, system managers and contributors of MTS and MHS reports received on contributions.	
AC-report-summary	M	See AC-correlated-report-list.	
AC-uncorrelated-report-list	M	See AC-correlated-report-list.	
Alternate-recipient-allowed	S	Used as for distribution lists in X.411/X.413.	
Child-sequence-numbers	M	Used as in X.413. Separate for each ACC-SA and not forwarded between ACC-SA-s (except implicitly by forwarding a contribution with children as a composite object).	
Content-type	S	Used as in X.411/X.413.	
Conversion-with-loss-prohibited	S	Used as in X.411/X.413.
FFS: Does the ACC service provide any conversion service for contributions? (Priority = 2, June 1993)	
Converted-EITs	M	Used as in X.411/X.413.	
Creation-time	S	See section %.%.%.	
DL-expansion-history	M	Used as in X.411/X.413. Only used to show DL distribution. ACC distribution is shown in the return-path attribute, see %.%.%.	
Implicit-conversion-prohibited	S	Used as in X.411/X.413.	
Lapsed-time, Lapsed-time-differential	S	Used as in X.413. This attribute is particular to each ACC-SA storage, and is not forwarded between ACC-SA-s.	
Message-delivery-envelope	S	Only available for objects which have been forwarded as MTS messages.	
MS-submission-error	S	Only available if the ACC-SA has tried to submit a contribution via the MTS.	
Original-EITs	M	Used as in X.413.	
Originally-intended-recipient-name	S	Used as for distribution lists in X.411/X.413.	
Originator-name	S	See section %.%.%.	
Originator-return-address	S	Used as in X.413.	
Parent-sequence-number	S	Used as in X.413. Separate for each ACC-SA and not forwarded between ACC-SA-s.	
Mt-priority	S	See section %.%.%.	
Recipient-reassignment-prohibited	S	Used to prohibit automatic forwarding not only between MTS recipients, but also between activities.	
Reporting-DL-name	S	Used as in X.411/X.413. Also used in reports to managers of activities use this attribute to indicate the name of the activity in which the report was generated.	
Retrieval-status	S	See section %.%.%.	
Sequence number	S	Used as in X.413. Separate for each ACC-SA and not forwarded between ACC-SA-s.	
This means that the following attributes are not imported from X.411-X.413 to the ACC service: Auto-action-error, auto-action-registration-identifier, auto-action-subject-entry, auto-action-type, content, content-confidentiality-algorith-identifier, content-correlator, content-identifier, content-integrity-check, content-length, content-return-request, content-returned, deferred-delivery-cancellation-time, deferred-delivery-time, deletion-time, delivered-EITs, delivery-flags, disclosure-of-other-recipients, DL-expansion-prohibited, entry-type, latest-delivery-time, marked-for-deletion, message-delivery-identifier, message-delivery-time, message-group-name, message-notes, message-origin-authentication-check, message-security-label, mesage-submission-envelope, message-submission-identifier, message-submission-time, message-token, MS-originated, originating-MTA-certificate, originator-certificate, originator-report-request, other-recipient-names, per-recipient-message-submission-fields, per-recipient-probe-submission-fields, per-recipient-report-delivery-fields, probe-origin-authentication-check, probe-submission-envelope, proof-of-delivery-request, proof-of-submission, recipient-names, redirection-history, report-delivery-envelope, reporting-MTA-certificate, report-origin.authentication-check, security-classification, subject-submision-identifier and this-recipient-name.
Even though these attributes are not imported into the ACC service, the attributes can occur on ACC contributions, when such contributions are submitted to, or transported via the MTS.
Note – Originator-report-request in X.413 is in X.acc replaced by submittor-report-request.
AttributeTable ATTRIBUTE ::= {
acc-aliases | acc-originator | acc-free-form-name ... FFS to be completed }
FFS: Can we reduce the number of new attributes by replacing some of the attributes above with those defined in X.413? (Priority = 4a, June 1993)
FFS: Do we copy all attributes defined in X.413 and X.420, or only some of them? (Priority = 1, June 1993)
8.4	ACC object hierarchy (inheritance of attributes)
Figure 7-0 shows the main lines of inheritance of attributes between Group Communication and Computer Conferencing objects.

Figure 7-0
Computer Conferencing 
acc-top
							
acc-object
							
item
						parti-cipant	
contribution	link
				notification
	activity
	
	superactivity,
open-for-member, open-for-observer,
closed-for
	replied-to,
obsoleted,
related	role

member,
hidden-member,
owner,
administrator,
observer,
contributor,
moderator	primary-recipient,
copy-recipient,
blind-copy-recipient,
reply-recipient,
followup-to,
submission-link,
acceptance-decision,

accepted-contribution,
rejected-contribution	attribute-adder,
attribute-subtractor,
object-inhibitor,
object-burner,
presence-report,
subscription-change,
membership-decision,
memberlist-finder,
memberlist-report,
update-distribution,
update-distribution-confirmation,
routing-report-request,
routing-report	activity-announcement	
Table %
Full computer Conferencing 
FFS: The definition av ACC contributions as a subclass of IPM has the disadvantage that the ACCS will not easily handle contributions based on other content types than IPM. Should we do anything about this? If so, what? (Priority=1, June 1993)
8.5	ACC 
This section specifies the superclass of all ACC objects, containing attributes which are common to all computer conferencing objects.
8.5.1	Notation
The OBJECT-CLASS and ATTRIBUTE macros used here are imported from X.413.
8.5.2	

	SUBCLASS OF acc-top
	MUST CONTAIN {
		acc-class-type,
		acc-name,
		ms-originator-name, - - syntax defined in X.413
		acc-original-creation-time,
		ms-creation-time - - as defined in X.413
		ms-sequence-number, - - as defined in X.413
	}
	MAY CONTAIN {
		return-path,
		acc-dummy,
		ms-retrieval-status,
		acc-master-SA, - - mandatory if acc-master-copy-controlled or master-copy-distributed or
					- - master-copy-membership-handling is true
		acc-free-form-name,
		acc-last-modification-time,
		acc-last-modifier,
		acc-status,
		acc-locked-by,
		acc-retention-period,
		acc-master-copy-controlled,
		acc-non-modifyable,
		acc-distribution-area-list,
		acc-keywords,
		acc-authorizing-users,
		ms-alternate-recipient-allowed, - - as defined in X.413
		ms-child-sequence-numbers, - - as defined in X.413
		ms-content-type, - - as defined in X.413
		ms-DL-expansion-history, - - as defined in X.413
		ms-message-delivery-envelope, - - as defined in X.413
		ms-submission-envelope, - - as defined in X.413
		ms-originally-intendend-recipient-name, - - as defined in X.413
		ms-originator-return-address, - - as defined in X.413
		ms-parent-sequence-number, - - as defined in X.413
		mt-priority, - - as defined in X.413
		ms-recpient-reassignment-prohibited, - - as defined in X.413
		ms-reporting-DL-name, - - as defined in X.413
	}
	::= {acc-class-accObject}
8.5.3	
This attribute contains the object identifier for the OBJECT-CLASS of this object.

	WITH ATTRIBUTE-SYNTAX
		AccClassType
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
::= OBJECTIDENTFIER
8.5.4	
This attribute gives a name to each computer conferencing object. The name will in most cases be globally unique, the only exception from this is some IPMessages entered from MHS (1984 version) to computer conferencing.
The name of computer conferencing objects should never be changed, since this will make all old links referring to the old name invalid, unless all these links are changed at the same time, something which will be very difficult to achieve in a distributed application.
If there is a need to change the name of a computer conferencing object (e.g. changing the name of an activity to reflect a change in topic), it is recommended to only change the free-form-name, not the formal-name. Another alternative to a name change can in some cases be to create a new activity or participant to replace the old activity or participant. Member lists and contributions can, if necessary, be copied to the new activity, and submissions to the old activity can be automatically rerouted to the new activity.

	WITH ATTRIBUTE-SYNTAX
		ACCObjectName
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
::= CHOICE {
			[0] ORName, - - as defined in X.411 
						- - but with mandatory directory-name
			[1] ORName, - - as defined in X.411
		[2] IPMIdentifier, - - as defined in X.420
			[3] LinkName - - as defined below
	}
8.5.4.1	
The name of an activity is an OR-name in the same format as in the name of an MHS users. However, within the , the directory-name component is mandatory, and the COMPONENTS OF ORAddress part is mandatory when transporting a message destined for a group activity via the MTS. The COMPONENTS OF ORAddress part is also mandatory in the definition of any group activity which is going to communicate via the MTS.
Each ACC activity shall have a globally unique distinguished directory name. The OR-address of the activity, if available, shall also be globally unique, so that contributions sent via the MHS can unambiguously be directed to a particular activity.
The directory name component is mandatory in the definition of an activity, and should be included in information distributed from the activity (except 1984 MHS distribution). However, the directory name component is not mandatory in contributions and other information objects sent to the activity via the MHS.
Note – The use of directory names for activities does not require the existence of a globally interconnected directory system, but it does require the existence of a global directory naming tree.
An ACC activity shall have an OR-Address if it can receive contributions transported via the MTS. In such a case, the ACC-SA shall, when the activity is created, register its OR-Address with a suitable MTS MTA.
Within the ORAddress part of the ORName, it is recommended to use the CommonName rather than the PersonalName for the naming of group communication activities.
If an ACC activity allows participation for MHS users, then such MHS users should be able to send contributions to the activity through the MHS, using the ORName which is the activity-name of that activity.
In this case, the ACC activity will look, to the MHS user, as a distribution list as defined in MTS.
The directory system should translate Directory Names into OR-addresses in the same way for ACC as for MHS names, and should for objects reachable via MTS return the same OR-address whether looked-up for ACC usage or for MHS usage.
Note – The naming scheme described above means that if the name of an activity is changed, references to that activity are no longer valid. Because of this, changes of the name of activities are strongly discouraged. A changed topic should reflect in a change in the free-form-name but not in the formal-name of the activity.
FFS: Is this OK? (Priority = 1, June 1993)
8.5.4.2	
ACC participants should be reachable via interpersonal mail, sent through the MHS to the ORName which is the participant-name of the participant.
8.5.4.3	
The contribution identifier for ACC contributions has the same format as the IPM Identifiers, and when a contribution is transported via the MHS, its contribution identifier will be identical to its IPM Identifiers as presented to MHS subscribers to the activity.
FFS: At the Tokyo meeting, we agreed on the naming of activities, participants and contributions as described above. We did not agree on how to name contributions to pre-moderated activities. Such contributions can either have only the name given by the original contributor, or they can have an additional name given to them at the acceptance. In the latter case, the IPM forwarding format might be used. Note also, that some existing conference systems require each contribution to have a name in a naming space controlled by the activity. So maybe, we should specify that all conference contributions are to have two names, one given by the originator and one given at acceptance into the activity? (Priority = 1, June 1993)
8.5.4.4	
::= SEQUENCE {
	ipmid-part		IPMIdentifier, - - as defined in X.420
	link-type		AccClassType,
	link-position	INTEGER (0<..MAX) DEFAULT 1	- -  position of link in sequences of more
										- - than one of the same type
	}
Note – This construct of the LinkName is in order to allow several links to be combined and transported within one MTS message. The ipmid-part is then the name of this MTS message, and the link-position is the position in an enumeration of links of the same link type which are transported within an MTS message content header.
8.5.5	
ACC activities can have alias names. Such alias names have the format of directory alias names.

	WITH ATTRIBUTE SYNTAX
		SET OF Name - - as defined in X.501
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 12}
8.5.6	
This attributes identifies the participant who created this object and entered it into the ACC service.
Syntax as defined in X.413, but used in the ACCS for all kinds of ACC objects, not as in X.413 only for messages/contributions.
8.5.7	
This data type is used to combine the formal name of an object with a free-form-name, which is user-friendly but not necessarily globally unique. No free-form-name is available for contributions.
::= SET {
	formal-name		ACCObjectName, - -  as defined above
	free-form-name	[0]	FreeFormName - -  as defined in X.420 
	}
FFS: As an alternative to the FreeFormName as defined in X.420, the CaseIgnoreString as defined in X.520 might be used for the free-form-name attribute. (Priority = 2, June 1993)
8.5.8	
This data type contains an object name, which is not globally unique, but which is user-friendly and suitable for user interfaces.

	WITH ATTRIBUTE SYNTAX
		FreeFormName - - as defined in X.420
	MATCHES FOR EQUALITY SUBSTRINGS
	::= {acc-attribute-type 13}
8.5.9	
This attribute identifies the time when a computer conferencing object was created and entered into the ACC service.

	WITH ATTRIBUTE SYNTAX
		UTCTime - - as defined in X.208
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 14}
Note – This attribute has the name “Original-creation-time” to avoid confusion with “Creation-time”.
FFS: Who sets the acc-original-creation-time? The UA or the first service agent? (Priority = 2, June 1993)
8.5.10	
This attribute identifies the time when a computer conferencing object became available for retrieval from the storage of one particular computer conferencing service agent or user agent. The syntax for this attribute is as defined in X.413.
Note – The value of this attribute will thus usually be different in the store of each agent. This value may vary even for otherwise non-modifyable objects.
Note – This value has the name “Creation-time” in order to be compatible with the same attribute in X.413 | ISO/IEC 10021-5
8.5.11	This clause was deleted in version 13, since owner is a link, not an attribute
8.5.12	
The return-path attribute lists the ACC-SA-s (and, optionally, MHS MTA-s) which this object has traversed before coming to its present location. In gateways from MHS, information from the trace can be used to generate additional items in the return-path. If the same object arrives more than once to an ACC-SA, with different return-pathes, only the return-path from the first arriving object is preserved.

	WITH ATTRIBUTE SYNTAX
		SEQUENCE OF ORName - - only names of ACC-SA-s and MHS MTA-s
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
8.5.13	
This attribute indicates that this is a dummy or skeleton for an object not yet available. A dummy is replaced by its real object as soon as it arrives. The formal-name of a dummy is the same as the formal-name of the real object. If available, the acc-class-type, ms-originator-name and acc-original-creation-time are also available. Dummy objects are normally not distributed.

	WITH ATTRIBUTE SYNTAX
		AccDummy
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
AccDummy ::= ENUMERATED {
	not-a-dummy (0), - - default value if the attribute is omitted
	dummy (1), - - the real object has not arrived yet
	skeleton (2), - - the real object has been burned or purged
	incomplete-copy (3) - - the object arrived via MHS with the incomplete-copy flag set
}
8.5.14	
This attribute shows the last time when this object was modified.

	WITH ATTRIBUTE SYNTAX
		UTCTime - - as defined in X.208
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.5.15	
This attribute contains the name of a participant who has locked this object temporarily in order to modify it.

	WITH ATTRIBUTE SYNTAX
		ACCOobjectDescriptor
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
FFS: Operations to lock and unlock objects and to modify objects only while locked are not specified anywhere in this document (June 1993). (Priority = 2, June 1993)
8.5.16	
This attribute contains the name of the participant who made the last modification of this object.

	WITH ATTRIBUTE SYNTAX
		ACCOobjectDescriptor DEFAULT acc-originator
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
8.5.17	
This attribute can have the following values:
:	Normal status.	
:	No one can view this object.	
:	Can be viewed but not modified.	
:	Temporarily locked while being modified.	
:	Deleted, but might still be viewed and the deletion can be undone (period from logical deletion to physical deletion)	

	WITH ATTRIBUTE SYNTAX
		ACCOStatus
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
::= ENUMERATED {
	active (0), hidden(1), frozen (2), locked(3), inhibited(4) }
8.5.18	
This attribute gives a minimum time when this object should stay in the inhibited state before allowing it to be physically purged.

	WITH ATTRIBUTE SYNTAX
		TimeLapse
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
::= SEQUENCE {
	minutes	INTEGER (0 .. 59),
	hours		INTEGER (0 .. 23),
	days		INTEGER (0 .. MAX),
	}
8.5.19	
This attribute indicates whether all modifications of this object must be done via an ACC-SA holding a master copy of the object.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
8.5.20	
This attribute differs from other attributes in that it has a separate value for each user. Each user will however only see the value of this attribute for that user, so the attribute will look like any other attribute to that user.
Retrieval-status is only available on objects which are destined for a certain user, i.e. have been sent or made available to that user. Note that users may be allowed to retrieve objects in some actvities even if they are not members of those activities. They will then not see any retrieval-status on those objects.
The syntax of this attribute is defined in X.413.
8.5.21	
For a master-copy-controlled object, a master-copy-distributed activity or a master-copy-membership-handling activity, this attribute indicates which ACC-SA handles the master copy of the object.

	WITH ATTRIBUTE SYNTAX
		ACCOobjectDescriptor
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
8.5.22	
This attribute indicates whether other modifications than deletions, and changes to the acc-creation-time attribute, are allowed on the attributes of this object. 
Note – The addition and removal of links is not regarded as a modification.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
8.5.23	
This attribute indicates that this object should not be available outside a certain area, specified by the names of one or more server domains, geographical regions or organizations.

	WITH ATTRIBUTE SYNTAX
		SET OF ACCObjectDescriptor
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
When several objects are distributed as separate body parts within a digest, distribution-area-list in the outermost heading will control distribution of the whole set of objects. Distribution-area-list on embedded objects will in this case not have any effect.
If this attribute is used on an activity, then all contributions to that activity shall also be limited to the same distribution-area-list.
FFS: What kind of area names are to be used in DistributionAreaList? (Priority = 2, June 1993)
8.5.24	
This attribute gives keywords for use in searches for this object.

	WITH ATTRIBUTE SYNTAX
		SET OF Keyword
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
::= CaseIgnoreStringSyntax - - as defined in X.520
8.5.25	
This attribute is used as defined in X.420.

	WITH ATTRIBUTE SYNTAX
		AuthorizingUsersField - - as defined in X.420
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
8.6	Group activity (subclass to ACC Object)
8.6.1	

	SUBCLASS OF acc-object
	MUST CONTAIN {
	}
	MAY CONTAIN {
		activity-description,
		moderation-policies,
		anonymous-allowed,
		anonymous-required,
		hidden-members-allowed,
		member-list-available,
		activity-task,
		non-members-can-submit,
		ip-submission-forbidden,
		size-limitation-on-contributions,
		size-limitation-on-replies,
		depth-limitation-on-contributions,
		allowed-body-part-types,
		expiry-time,
		languages,
		importance,
		organizations,
		default-expiry-time,
		master-copy-distributed,
		master-copy-membership-handling,
		mhs-submission-allowed,
		mhs-distribution-allowed
	}
	::= { acc-class-activity}
Within an accGroup-activity, the ACCObjectName has the activity-name format, master-copy-controlled is defaulted to TRUE and non-modifyable is defaulted to FALSE.
FFS: (How can this be encoded in ASN.1?) (Priority = 3a, June 1993)
8.6.2	
This attribute gives a description of the topic of this conference, intended for members who want to know what fits within the topic, and for non-members who wamt to decide whether to join the conference.

	WITH ATTRIBUTE SYNTAX
		Case-ignore-string - - as defined in X.500
	MATCHES FOR EQUALITY SUBSTRINGS
	::= {acc-attribute-type 15}
8.6.3	
This attribute gives information about the moderation policies applicable in this activity.

	WITH ATTRIBUTE SYNTAX
		ModerationPolicy
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
::= ENUMERATED {
	unmoderated(0), postmoderated(1), premoderated(2), only-moderator-submits(3),
	 temporal-moderated(4)
	} - - For “premoderated” activities, contributions are invited, but not for “only-moderator-submits”
8.6.4	
When this attribute is TRUE, anonymous or pseudonymous contributions are accepted in this activity. Handling of anonymous or pseudonymous contributions is FFS in this version of this recommendation.
FFS: Is this OK? (Priority = 1, June 1993)

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
8.6.5	
When this attribute is TRUE, all contributions to this activity must be anonymous or pseudonymous.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
8.6.6	
When this attribute is TRUE, the activity can have members, whose existence are not divulged to other members.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
8.6.7	
When this attribute is TRUE for a master-copy-membership-handling activity, lists of all members of this activity everywhere are compiled at the master ACC-SA and can be retrieved (subject to access controls). When this attribute is TRUE for a non-master-copy-membership-handling activity, lists are only available of local members connected to that ACC-SA. When the attribute is FALSE no lists of members are available for this activity.
Lists of owners and moderators are available regardless of the value of this attribute.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT TRUE
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
8.6.8	
This attribute can be used to describe different kinds of activities.

	WITH ATTRIBUTE SYNTAX
		ActivityTask DEFAULT {asynchronous-computer-conferencing}
	MATCHES FOR EQUALITY SUBSTRINGS
	::= {acc-attribute-type 15}
ActivityTask ::= BIT STRING { asynchronous-computer-conferencing(0), voting(1), joint text production(2), help-desk(3)}
ActivityTask ::= OBJECT IDENTIFIER
Pre-defined values:

 ::= {acc-task-2}
 ::=  {acc-task-3}
::= {acc-task-4}
8.6.9	
When this attribute is true, submissions from non-members are accepted for this activity.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT TRUE
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.6.10	
This attribute indicates which content types are allowed for this activity.

	WITH ATTRIBUTE SYNTAX
		SET OF ContentType - - ContentType as defined in X.411
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.6.11	
This attribute specifies a maximum size in number of characters of non-replying contributions to this activity.

	WITH ATTRIBUTE SYNTAX
		INTEGER DEFAULT MAX
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.6.12	
This attribute specifies a maximum size in number of characters of contributions to this activity which are related to other contributions.

	WITH ATTRIBUTE SYNTAX
		INTEGER DEFAULT MAX
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.6.13	Depth-limitation-on-contributions
This attribute specifies a maximum depth of conversations within this activity.

	WITH ATTRIBUTE SYNTAX
		INTEGER DEFAULT MAX
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.6.13	Allowed body part types
This attribute specifies which body part types are allowed in contributions to this activity.

	WITH ATTRIBUTE SYNTAX
		AllowedBodyPartTypes DEFAULT NONE - - None indicates that any body part type is allowed
	MATCHES FOR EQUALITY SUBSETTING
	::= {acc-attribute-type 15}
AllowedBodyPartTypes::= SEQUENCE OF OBJECT IDENTIFIER 
- - with allowed values as defined in X.420 Annex D
8.6.14	
This attribute indicates a future data when this activity will be frozen or deleted.

	WITH ATTRIBUTE SYNTAX
		UTCTime
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.6.15	
This attribute indicates one or more languages used within an activity.

	WITH ATTRIBUTE SYNTAX
		SET OF Language - - As defined in X.420 Annex A
	MATCHES FOR EQUALITY SUBSTRINGS
	::= {acc-attribute-type 15}
8.6.16	
This attribute gives a priority classification of the activity according to the views of the owner of the activity.

	WITH ATTRIBUTE SYNTAX
		Importancefield - - As defined in X.420
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.6.17	
This attribute gives the names of one or more organization responsible for running this activity.

	WITH ATTRIBUTE SYNTAX
		SEQUENCE OF ACCObjectDescriptor
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.6.18	This clause was removed at the Tokyo meeting 1993
8.6.19	
This attribute contains a default expiry time to be applied to contributions in this activity which do not have a different explicit expiry time.

	WITH ATTRIBUTE SYNTAX
		TimeLapse
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.6.20	
When this attribute is true, all contributions must first be entered into the master copy of the activity.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.6.21	
When this attribute is true, membership of an activity is controlled by the master copy of this activity. When the attribute is false, membership is handled locally by each ACC-SA for its local participants.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.6.22	MHS-submission-allowed
When this attribute is true, input contributions from IPM users are allowed. The activity will look, to them, like an MTS distribution list.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT TRUE
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.6.23	MHS-distribution-allowed
When this attribute is true, contributions from this activity may be distributed as MTS messages to members holding IPM UA-s only. The activity will look, to them, like an MTS distribution list.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT TRUE
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.7	This section was removed at the Tokyo 1993 meeting
8.8	Participant (subclass to ACC Object)
8.8.1	

	SUBCLASS OF acc-object
	MUST CONTAIN {
	}
	MAY CONTAIN {
		participant-description,
		locality-name, - - defined in X.520
		stateOrProvince Name, - - defined in X.520
		streetAddress, - - defined in X.520
		title, - - defined in X.520
		postalAddress, - - defined in X.520
		postalCode, - - defined in X.520
		postOfficeBox, - - defined in X.520
		physicalDeliveryOfficeName, - - defined in X.520
		telephoneNumber, - - defined in X.520
		teletexTerminalIdentifier, - - defined in X.520
		facsimileTelephoneNumber, - - defined in X.520
		participant-preferred-delivery-method, 
		last-present,
		participant-statistics
		}
	::= { acc-class-participant}
Within a participant, the ACCObjectName has the participant-name format, master-copy-controlled is defaulted to TRUE and non-modifyable is defaulted to FALSE.
The attributes for participants are stored in the ACC-SA for this user. The ACC-SA may use the directory to store this information, and if the information is stored in the directory, it may be available to users of other ACC-SA-s via the directory. Access control may limit who can access some or all of the attributes of participants. For example, participant-statistics might be available only to the participant him/herself and to the system administrator for the ACC-SA to which the participant is connected.
8.8.2	
A personal description, written by this user, of information which s/he wants to provide to others, like interests, tasks etc.

	WITH ATTRIBUTE SYNTAX
		CaseIgnoreString
	MATCHES FOR EQUALITY SUBSTRINGS
	::= {acc-attribute-type 15}
8.8.3	
When this attribute is true, submissions from non-members are accepted for this activity.

	WITH ATTRIBUTE SYNTAX
		ACCPreferredDeliveryMethod
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
::= SEQUENCE OF INTEGER {
	any-delivery-method	(0),
	mhs-delivery	(1),
	physical-delivery	(2),
	telex-delivery	(3),
	teletex-delivery	(4),
	g3-facsimile-delivery	(5),
	g4-facsimile-delivery	(6),
	ia5-terminal-delivery	(7),
	videotex-delivery	(8),
	telephone-delivery	(9),
	ACC-service-agent-retrieval	(10),
	DFR-retrieval-delivery	(11)
	} - - extension of similar definition in X.520
By is meant that the contribution is stored in an asynchronous computer conferencing service agent, and that the asynchronous computer conferencing user agent connects to this service agent and issues retrieval operations in order to get new contributions in the activities to which the user subscribes.
FFS: Should we have DFR-retrieval? Or MS-retrieval? Or both? If so, they need to be defined. (Priority = 1, June 1993)
8.8.4	
Gives information on the last time that this participant accessed the computer conferencing service. This attribute is updated every time the ACC-UA for this user connects to its ACC-SA with the bind operation. This information is available for local connections to the user ACC-SA. If the ACC-SA uses the directory system to store information about participants, this information may be available outside the user ACC-SA through the directory system.

	WITH ATTRIBUTE SYNTAX
		UTCTime
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.8.5	
When this attribute is true, submissions from non-members are accepted for this activity.

	WITH ATTRIBUTE SYNTAX
		ParticipantStatistics
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
::= SEQUENCE {
	total-access-count		[0] INTEGER (0 . . MAX) OPTIONAL, - - No. of times that the
						ACC system was accessed by this user since creation
	total-minutes-connected	[1] INTEGER (0 . . MAX) OPTIONAL, - - No. of minutes that
						the ACC system has been accessed by this user since
						creation
	total-messages-sent	[2] INTEGER (0 . . MAX) OPTIONAL, - - No. of contributions
						- - and messages sent by this user using the ACC and an
						- - associated MHS system since creation
	last-month-access-count	[3] INTEGER (0 . . MAX) OPTIONAL, - - No. of times that the 
						- - ACC system was accessed by this user during the last
						- - full calendar month
	last-month-minutes-connected [4] INTEGER (0 . . MAX) OPTIONAL, - - No. of minutes that
						- - this user has been connected to the ACC system during
						- - the last full calendar month
	last-month-messages-sent	[5] INTEGER (0 . . MAX) OPTIONAL - - No. of contributions
						- - and messages sent by this user using the ACC and an
						- - associated MHS system during the last full calendar
						- - month.
	} - - end of ParticipantStatistics definition
8.9	
A computer conferencing item is an information object which is created by a participant and distributed within one or more activities. Contributions, notifications and links are different kinds of items.

	SUBCLASS OF acc-object
	MUST CONTAIN {
	}
	MAY CONTAIN {
	expiry-time,
	sensitivity,
	auto-submission-indication,
	mt-priority,
	ms-AC-correlated-report-list, - - as defined in X.413
	ms-AC-report-summary, - - as defined in X.413
	ms-AC-uncorrelated-report-list, - - as defined in X.413
	ms-lapsed-time, - - as defined in X.413
	ms-lapsed-time-differential, - - as defined in X.413
	}
	::= { acc-class-item}
8.10	
A computer conferencing contribution is called a submission when it is sent from its originator to the group activity, and is called an acepted contribution when it has been accepted by the group activity. A pure IPMessage, generated by a messaging UA, is accepted as a submission unless explicity forbidden by the IP-submission-forbidden attribute of the activity.
	SUBCLASS OF acc-item
	MUST CONTAIN {
	}
	MAY CONTAIN {
	subject,
	summary,
	lines,
	reply-time,
	importance,
	auto-forwarded,
	request-for-acceptance-notification,
	suppression-of-rejection-notification,
	contribution-language,
	incomplete-copy,
	digest,
	ms-converted-EIT-s, - - as defined in X.413
	ms-implicit-conversion-prohibited, - - as defined in X.413
	ms-original-EIT-s, - - as defined in X.413, - - as defined in X.413
	body
	}
	::= { acc-class-contribution}
Within a contribution, the ACCObjectName has the contribution-identifier format, master-copy-controlled is defaulted to FALSE and non-modifyable is defaulted to TRUE.
8.10.1	
Semantics as defined in X.420.

	WITH ATTRIBUTE SYNTAX
		SubjectField - - as defined in X.420
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.10.2	
The summary can be used to give a short abstract of a long contribution.

	WITH ATTRIBUTE SYNTAX
		CaseIgnoreString - - as defined in X.500
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.10.3	
Gives a rough estimate of the size of the contribution. Can be used when an ACC-UA first downloads heading without bodies, before deciding whether to get the body.

	WITH ATTRIBUTE SYNTAX
		INTEGER
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.10.4	
Semantics as defined in X.420.

	WITH ATTRIBUTE SYNTAX
		ExpiryTimeField - - as defined in X.420
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.10.5	
This field gives a desired reply time both for personal replies to the author and to group replies to the whole group.

	WITH ATTRIBUTE SYNTAX
		ReplyTimeField - - as defined in X.420
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.10.6	
Semantics as defined in X.420.

	WITH ATTRIBUTE SYNTAX
		ImportanceField - - as defined in X.420
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.10.7	
Semantics as defined in X.420. Applies to all recipients within a group.
sensitivity ATTRIBUTE
	WITH ATTRIBUTE SYNTAX
		SensitivityField - - as defined in X.420
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.10.8	
Semantics defined in X.420.

	WITH ATTRIBUTE SYNTAX
		AutoForwardedField - - as defined in X.420
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.10.9	Request-for-acceptance-notification
This attribute indicates that the originator wants a notification of acceptance when this contribution is accepted to the activities it is sent to. It can be used for all activities which have some kind of access control on submission. This includes, but is not limited to, pre-moderated activities.
request-for-acceptance-notification ATTRIBUTE
	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.10.10	Suppression-of-rejection-notification
This attribute indicates that the originator does not wants a notification of rejection if this contribution is not accepted to the activities it is sent to.
suppression-of-rejection-notification ATTRIBUTE
	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.10.11	
Semantics defined in X.420.

	WITH ATTRIBUTE SYNTAX
		Languages - - as defind in X.420 Annex A
	MATCHES FOR EQUALITY SUBSTRINGS
	::= {acc-attribute-type 15}
8.10.12	
This attribute indicates by its present that one or more body parts may be missing from this copy of this contribution.

	WITH ATTRIBUTE SYNTAX
		NULL - - as defined in X.420 Annex A
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.10.13	
Semantics as defined in X.420.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT FALSE - - as defined in X.420 Annex A
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.10.14	
This attribute indicates a priority assigned to this contribution by its originator.
Syntax is as defined for mt-priority in X.413.
8.10.15	
When several independently created objects are sent as body parts under a common heading, then the digest attribute in the common heading shall have the value TRUE. In the ACC-SA-store, such body parts are stored as child entries to the digest entry. If the body parts cause actions from the ACC-SA, then such actions are performed as if each body part had been submitted separately, except that the ACC-SA can distribute the digest in digested format to other ACC-SA-s and to ACC-UA-s.

	WITH ATTRIBUTE SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
 An ACC-SA can combine several contributions, independently sent to it, into a digest before further distribution of them.
All contributions within a digest must have the same activities as recipients (i.e. be submitted to the same activities). The distribution-area-list attribute on the surrounding heading will control the distribution of the whole digest. The distribution-area-list on embedded objects will not have any effect on their distribution, as long as they are re-sent embedded in the digest.
8.10.16	

	WITH ATTRIBUTE SYNTAX
		Body - - as defined in X.420
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.10.17	
FFS: The above includes all IPM heading fields plus additional computer conferencing fields. But should also some other MTS envelope field than priority be included in the contribution object??? (Priority = 1, June 1993)
8.11	Modification of contributions
The original contribution-object itself cannot be modified except by burning. The user view of the object can however be modified by the attribute-adders, attribute-removers and inhibitors. Also links referring to the object may to the user appear as modifications of the object. Finally, a contribution can be modified by an obsoleting contribution.
8.12	
8.12.1	

	SUBCLASS OF acc-item
	MUST CONTAIN {
		link-from,
		link-to
	}
	MAY CONTAIN {
		submittor-report-request
	}
	::= { acc-class-link}
Each type of link has a separate value in the acc-class-type attribute.
Within an acc-link, the ACCObjectName has the link-identifier format, master-copy-controlled is defaulted to FALSE and non-modifyable is defaulted to TRUE.
8.12.2	
This attribute gives the name of the object from which this link goes.

	WITH ATTRIBUTE SYNTAX
		ACCObjectDescriptor
	MATCHES FOR ACC-EQUALITY 
	::= {acc-attribute-type 15}
Note – The type of the ACCObjectDescriptor is limited by the link-type, since certain link-types are only allowed to link certain types of objects.
8.12.3	
This attribute gives the name of the object to which this link goes.

	WITH ATTRIBUTE SYNTAX
		ACCObjectDescriptor
	MATCHES FOR ACC-EQUALITY 
	::= {acc-attribute-type 15}
Note – The type of the ACCObjectDescriptor is limited by the link-type, since certain link-types are only allowed to link certain types of objects.
8.12.4	
This attribute indicates what kind of reports the submittor wants from the distribution using this link.

	WITH ATTRIBUTE SYNTAX
		AccSubmittorReportRequest
	MATCHES FOR ACC-EQUALITY 
	::= {acc-attribute-type 15}
::= BIT STRING {
	rn (0), - - as defined in X.420
	nrn (1), - - as defined in X.420
	ipm-return (2), - - as defined in X.420
	report (3), - - as defined in X.411
	non-delivery-report (4), - - as defined in X.411
	acceptance-notification-requested (5), - - for submissions to activities
	rejection-notification-suppressed (6), - - for submissions to activities
}
The and the indicate whether the originator wants a notification of acceptance or rejection when the contribution distributed via this link is accepted or rejected. They can be used for all activities which have some kind of access control on submission. This includes, but is not limited to, pre-moderated activities.
8.12.5	
This attribute gives the type of the link.

	WITH ATTRIBUTE SYNTAX
		LinkType - - as defined earlier
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.12.6	
Here is a list of the link types used in the basic computer conferencing application:
link-type	OBJECTIDENTFIER	Description	
		Links from contributions to group activities and to participants	
Primary-recipient	to be completed	Links a contribution to the group activities or interpersonal recipients it is primarily submitted.	
Copy-recipient	to be completed	Links a contribution to the group activities or interpersonal recipients to which copies of the contribution are submitted.	
Blind-copy-recipient	to be completed	Links a contribution to the group activities or interpersonal recipients to which copies of the contribution are submitted without informing other recipients.	
Reply-recipient	to be completed	Links a contribution to individuals, to whom interpersonal replies are to be sent. Not to be used for replies intended for all the recipients of the contribution.	
Followup-to	to be completed	Links a contribution to individuals and group activities to which replies intended for all the recipients of the contribution are to be sent.
FFS: Should Follwup-to be restricted to refer to only one activity, or be allowed to refer to more than one? Should Followup-to be allowed to refer to inter-personal mailboxes? (Priority = 1, June 1993)	
Submission-link	to be completed	Links a contribution to the activity, to which it was submitted. Only exists in the master ACC-SA for this activity, and will be removed when the submission has been accepted or rejected.	
Acceptance-decision	to be completed	Links a contribution to the activity, for which the acceptance-decision is taken.	
Accepted-contribution	to be completed	Subclass of acceptance-decision for accepted contributions.	
Rejected-submission	to be completed	Subclass of acceptance-decision for rejected contributions.	
		Links from contributions to other contributions	
Replied-to-IPM	to be completed	Links a contribution to another contribution which it is a direct reply to. Mostly used for replies sent directly to individuals and not to group activities.	
Obsoleted-IPM	to be completed	Links a contribution to a previous contribution which the new contribution obsoletes.	
Related-IPM	to be completed	Links a contribution to other contribution which it refers to. Should be used for comments on previous entries within group activities.	
	to be completed	Links from participants (or groups of participants represented by activities) to group activities (Roles)	
Owner	to be completed	The owner of an object has the ability to execute all possible privileges that can be associated with the object.	
Administrator	to be completed	This is a participant who may add or remove other participants from membership in a given communication activity and assign their roles within the context of that activity.	
Member	to be completed	A member (also called regular member) of an ACC activity has the privileges of submitting and getting communication items within that activity. For a pre-moderated activity, submissions will still be subject to acceptance or rejection by the moderators.	
Hidden-member	to be completed	A member, whose membership is not divulged to other members.	
Observer	to be completed	This is a member who is not allowed to submit contributions within an ACC activity, but can view or observe what is there. If an observer tries to submit contributions, these will be automatically rejected by the access controls.	
Contributor	to be completed	A member who can create ACC items within an activity but not view other items within the activity.	
Moderator	to be completed	A participant or set of participants given the privilege to make modifications to any objects in an ACC activity. Can also refer to an organizational person.	
		Links between group activities	
Super-activity	to be completed	Refers from a sub-activity to its super-activity. The same activity can be sub-activity to more than one super-activity.	
Open-for-member	to be completed	An open-for link is a sub-activity link which also conveys the privilege, to members of the superactivity, of making themselves into regular members of the sub-activity.	
Open-for-observer	to be completed	Similar to the open-for link, but only allows users to join the activity as observers, i.e. participants with only read access and no direct write access to the activity. This is the normal way of offering membership to pre-moderated activities.	
Closed-for	to be completed	A closed-for link is a subactivity link which does not convey any privileges.	
Note – When a link is created, both the objects referred to by the link must exist. Later on, one or both of them may be inhibited, burned or purged. A link, for which either the Link-from or the Link-to is unavailable is called a corrupted link. Links are allowed to be corrupted. A corrupted links does not automatically become non-existent. How corrupted links are displayed to users is not prescribed here, except that ACC systems should be capable of handling such links.
8.12.7	
Tickets are link objects which can be used by a participant who has certain privileges over certain objects, in order to give these privileges to additional participants. Tickets may be cancelled at anytime by the originating participant.
Example: Passing the right to obsolete a contribution from the author to other participants.
FFS: Tickets require much further clarification. (Priority = 1, June 1993)
FFS: Validation of tickets in a distributed environment. (Priority = 1, June 1993)
8.12.8	
Links to contributions are distributed to the members of the activity to which the contribution was accepted, usually together with the contribution itself.
When certain kinds of links have been produced, the link objects may be sent separately as notifications to the originator and recipients of the contribution. In this way, a user may for example be informed if the moderator in a post-moderated activity has moved his contribution to another activity, or that some user has re-sent his contribution somewhere.
In similar ways, a manager of an activity may be informed of participants becoming members of or withdrawing from the activity.
8.12.9	The seen relation (subclass to ACC Link)
This clause was removed in version 13 of X.acc (June 1993), see the definition of retrieval-status as an attribute above for a replacement.
The seen relation between an ACC participant and an ACC object determines whether this participant has seen this object before. The internal format of and storage of this relation in the GCSA serving this user is a local implementation matter. The seen relation can have three values: New, Listed and Processed.
acc-seen OBJECT-CLASS
	SUBCLASS OF acc-link
	MUST CONTAIN {
		retrieval-status
	}
	MAY CONTAIN {
	}
	::= { acc-object-Class 2}
retrieva-status ATTRIBUTE
	WITH ATTRIBUTE SYNTAX
		Entry-status - -	as defined in X.413 | ISO/IEC 10021-5, with three values new, listed and 
					processed.
	MATCHES FOR EQUALITY 
	::= {acc-class-seen}
FFS: What kind of objects can have seen relations? Contributions? Notifications? Links? Group Activities? All ACC objects?
8.13	
8.13.1	
A role is a link from a participant to a group actvity (see figure %)
.
Figure %
A number of 
Common to all these links is that they can go from either a group activity or a participant to another group activity. If they go from a group activity, they mean the same thing as if there had been a separate link of the same type from all the members of that activity (see figure %).

Figure %
Several . The structure in figure % is functionally identical to the structure in figure %.
This means that if there is a set of ten participants who have the same role types, they are all e.g. moderators and administrators at the same time, we do not need a separate set of ten links for each of these roles. Instead, we create a sub-activity containing these ten participants, and then need only one link for each role type to the sub-activity.

	SUBCLASS OF acc-link
	MUST CONTAIN {
	}
	MAY CONTAIN {
		role-preferred-delivery-method,
		role-wants-all,
		role-last-present,
		role-statistics
	}
	::= { acc-class-role}
Each kind of role has a separate value in the acc-class-type attribute.
8.13.1.1	This clause was removed at the Tokyo 1993 meeting
8.13.1.2	This clause was removed at the Tokyo 1993 meeting
8.13.1.3	
This attribute indicates how objects for this role is to be delivered. If it is not given, the preferred-delivery-method for the participant who exercises this role is used.

	WITH ATTRIBUTE SYNTAX
		ACCPreferredDeliveryMethod
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.13.1.4	
This attribute indicates whether the role-holder wants all items in the activity, or only those items which can be mapped on the interpersonal-messaging-1988 (also known as P22) content type.
Note – an ordinary IPM UA cannot use the information in objects with the asynchronous-group-communication-1996 (also known as PACC) content type. Some IPM UA-s may however have been extended, so that they can also handle objects of the asynchronous-group-communication-1996 content type.

	WITH ATTRIBUTE SYNTAX
		RoleWantsAll BOOLEAN DEFAULT TRUE
	MATCHES FOR EQUALITY 
	::= {acc-attribute-type 15}
8.13.1.5	
Role-last-present gives information on the last time that this role-holder accessed the computer conferencing service in this role. This attribute is updated every time that the role-holder processes or contributes anything to this activity.
Note – the sending of new items from an activity to the ACC-UA is not enough to produce a presence report, the user must in some way tell his ACC-UA to handle items from this particular activity for role-last-present to be updated.
For a non-master-copy-membership-handling activity, this is only stored and available to users of the ACC-SA to which the user is connected, and only on role-holders within this ACC-SA.
For a master-copy-membership-handling activity, this is stored at the master ACC-SA.
 In order to update this value, a presence-report notification is sent from the ACC-UA to the master ACC-SA (for master-copy-membership-handling) or to the local ACC-SA (for non-master-copy-membership-handling activities) every time last-present is to be updated.
Note – A user may read and contribute items to some activities without being a member. No presence reports will then be produced.

	WITH ATTRIBUTE SYNTAX
		UTCTime
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.13.1.6	
Gives statistics about this role.
For a non-master-copy-membership-handling actvitiy, this is stored and available only in the local ACC-SA for this user.
For a master-copy-membership-handling activity, this is stored at the master ACC-SA. The master ACC-SA is able to compute the values from information available to it. The master ACC-SA then assumes that each contribution sent out during the time when this user was a member have also been sent to the role holder.

	WITH ATTRIBUTE SYNTAX
		RoleStatistics
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
::= SEQUENCE OF {
	received-objects		[23] INTEGER OPTIONAL, - - Number of contributions which have 
						- - been sent to this role holder which came via this activity
	submitted-root-objects	[24] INTEGER OPTIONAL, - - Number of root contributions which
						- - this role holder has submitted to this activity
	submitted-related-objects	[25] INTEGER OPTIONAL, - - Number of non-root objects
						- - this role holder has submitted to this activity
	}
8.13.2	, Hidden-member (subclasses to role)
The Owner, , . , and are subclasses of Roles with no added attributes. Their structure is thus:

OBJECT-CLASS
	SUBCLASS OF acc-role
	MUST CONTAIN {
	}
	MAY CONTAIN {
	}
	::= { acc-class-member}
	::= { acc-class-hiddenmember}
	::= { acc-class-owner}
	::= { acc-class-administrator}
	::= { acc-class-observer}
	::= { acc-class-contributor}
8.13.3	

	SUBCLASS OF acc-role
	MUST CONTAIN {
	}
	MAY CONTAIN {
	sees-rejected-submissions}
	::= { accclass-moderator}
8.13.4	

	WITH ATTRIBUTE SYNTAX
		boolean DEFAULT FALSE	- - Whether a moderator is shown submissions already rejected 							- - by another moderator.
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 15}
8.14	
8.14.1	Primary-recipient, Copy-recipient and Blind-copy-recipient
These are the links between a submission and the activity to which the submission was submitted, created by the submittor. They can also refer to MHS-recipients of the submission. These links are sent, together with the submission, to the activity, and are provided to the members of the activity together with the submission itself.
By default these links are also sent to the originator, if the originator is different from the submittor. By default, if a contribution is sent to more than one activity (at the same time, or at different times), then all the activities gets the links also to the other activities. These defaults are controlled by the submittor AC-UA and can be overridden by the submittor.

	SUBCLASS OF acc-link
	MUST CONTAIN {
	}
	MAY CONTAIN {
	}
	}
	::= { acc-class-primaryRecipient}
	::= { acc-class-copyRecipient}
	::= { acc-class -blindCopyRecipient}
8.14.2	Reply-recipient
Reply-recipient links are used to indicate to whom personal replies (only intended for the author) to contributions are to be sent as MHS messages.

	SUBCLASS OF acc-link
	MUST CONTAIN {
	}
	MAY CONTAIN {
	}
	}
	::= { acc-class-replyRecipient}
8.14.3	Followup-to
Followup-to links are used to indicate that forthcoming discussion, by group replies to this contribution, are to be submitted to the followup-to activities. The use of followup-to is recommended when a contribution is sent to more than one activity. If followup-to is not used, then group replies are by default sent to all the activities, unless the submittor overrides this default.
Note – followup-to is to be used to control group replies sent to activities, while reply-recipient is to be used to control personal replies intended only for the originator.

	SUBCLASS OF acc-link
	MUST CONTAIN {
	}
	MAY CONTAIN {
	}
	}
	::= { acc-class-followupTo}
8.14.4	
A submission-link links a submission to the activity, to which it was submitted. It is created by the master-ACC-SA for the activity when the submission arrives, and will be removed when the submission has been accepted or rejected. It is forwarded to the moderators, in order to instruct them to accept or reject the submission.

	SUBCLASS OF acc-link
	MUST CONTAIN {
	}
	MAY CONTAIN {
	}
	}
	::= { acc-class-submissionLink}
8.14.5	
An acceptance-decision is a link from a contribution to an activity. It is created by the moderator when deciding on acceptance of a contribution to a pre-moderated activity. It can also be created automatically by the server responsible for this activity. If a contribution is accepted or rejected more than once to the same activity, a separate acceptance-decision is made for each such acceptance. In such a case, previous acceptance-decisions may at the same time be inhibited or burned. If there is more than one non-inhibited and non-burned acceptance-decision from the same contribution to the same activity, the contribution is regarded as accepted as long as at least one of the decisions is favorable.
Actually, the moderator will create either an accepted-contribution or a rejected-submission link, not an acceptance-decision link. But both accepted-contribution and rejected-submission are subclasses of acceptance-decision.
If accepted, the acceptance-decision is distributed together with the contribution to the members of the activity.
An acceptance-decison may (depending on the content of the submittor-report-request attribute of the link) be sent to the submittor to tell him/her that his/her submission to a group activity has been accepted, rejected or removed (by a moderator or owner of the group activity, or automatically by the activity server). Accepted-contribution is only sent if the submittor requests it. Rejected-submission is sent unless the submittor requests its suppression. It is recommended, that accepted-contribution is also sent to the originator, if the originator is different from the submittor.
Note – This notification is sent to the submitter, which may not be the same as the originator of the contribution.

	SUBCLASS OF acc-link
	MUST CONTAIN {
		submission-reference,
		decision-taken,
	MAY CONTAIN {
		withdrawn-by-submittor,
		withdrawn-by-originator
	::= {acc-class-acceptanceDecision}
Note – The originator of the message being submitted need not be identical to the submittor.
FFS Access control: Who are allowed to see the submitted links and the contribution they refer to? Can any member of a conference see them (a) before acceptance (b) after acceptance (c) after rejection? (Priority = 1, June 1993)
8.14.5.1	
This attribute conveys a reference to the submission being accepted or rejected.

	WITH ATTRIBUTE SYNTAX
		ACCOobjectDescriptor
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
8.14.5.2	
This attribute indicates whether the submission is accepted or rejected.

	WITH ATTRIBUTE SYNTAX
		DecisionTaken
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
::= ENUMERATED { accepted (1), auto-accepted (2), 
	rejected (3), auto-rejected (4), withdrawn-by-submittor(5),
	withdrawn-by-originator(6)
 }
8.14.5.3	
Indicates that the participant who submitted this contribution has withdrawn it.

	WITH ATTRIBUTE SYNTAX
		BOLEAN DEFAULT FALSE
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
8.14.5.4	
Indicates that the participant who originated this contribution has withdrawn it.

	WITH ATTRIBUTE SYNTAX
		BOLEAN DEFAULT FALSE
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
8.14.6	
The accepted-contribution is similar in format to an acceptance-decision, but has its own value in the acc-class-type field. It is used in cases of positive acceptance, to trigger distribution to the members of the group. 

	SUBCLASS OF acc-acceptance-decision
	MUST CONTAIN {
	MAY CONTAIN {
	::= {acc-class-acceptedContribution}
8.14.7	
The rejected-submission link is similar in format to the acceptance-decision, but has its own value in the acc-class-type field. It is used in cases of negative acceptance, to inform other moderators and the submittor of the decision taken.

	SUBCLASS OF acc-acceptance-decision
	MUST CONTAIN {
	MAY CONTAIN {
		rejection-reason
	::= {acc-objectClass 1}
8.14.7.1	
This attribute contains arguments for rejecting this submission, which can be sent from the rejector to the submittor.

	WITH ATTRIBUTE SYNTAX
		Body - - as defined in X.420
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 15}
8.15	Links between contributions
8.15.1	Replied-to, Obsoleted, Related
Reply-recipient links are used to indicate to whom personal replies (only intended for the author) to contributions are to be sent as MHS messages. Related and obsoletes are used for replies intended for the activity members reading the related contribution.
Note that there is no automatic distribution of replying, obsoleting or relating contributions. In order to ensure that they are sent to their recipients (personal recipients or activities) the links from the referred-to contribution must be copied to the obsoleting or related contribution.

	SUBCLASS OF acc-link
	MUST CONTAIN {
	}
	MAY CONTAIN {
	}
	}
	::= { acc-class-repliedTo}
	::= { acc-class-obsoleted}
	::= { acc-class-related}
8.16	Links between activities
8.16.1	Super-activity, Open-for-member, Open-for-observer, Closed-for
These are links from a sub-activity to its superactvity. Open-for also conveys rights for everyone, who is a member of the superactvity, or is allowed to make him/herself into a member of the superactivity, the right to make him/her into a member of the subactivity.

	SUBCLASS OF acc-link
	MUST CONTAIN {
	}
	MAY CONTAIN {
	}
	}
	::= { acc-class-superActivity}
	::= { accclass-openForMember}
	::= { accclass-openForObserver}
	::= { accclass-closedFor}
8.17	
A notification is either an MTS-notification as definied in X.411, or an IPM-notification as defined in X.420, or a Computer-conferencing-notification.
8.17.1	ACC Notification common attributes

	SUBCLASS OF acc-item
	MUST CONTAIN {
	}
	MAY CONTAIN {
		confirmation-requested,
		immediate-confirmation,
		apply-to,
		triggered-by
	}
	::= {acc-class-notification}
Each type of notification has a separate value in the acc-class-type attribute.
8.17.1.1	Notification-type
This attribute contains the object identifier for the OBJECT-CLASS of this object.
notification-type ATTRIBUTE
	WITH ATTRIBUTE-SYNTAX
		OBJECTIDENTFIER
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
FFS: If each kind of notification is given a distinct acc-class-type value, then the attrbitue notification-type can be removed.
8.17.2.	
This attribute indicates that this notification applies to another ACC object, whose name is given in the attribute.

	WITH ATTRIBUTE-SYNTAX
		AccObjectDescriptor
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
8.17.3.	
This attribute indicates that a confirmation that the action requested by a requesting notification can or cannot be performed. Confirmations, if requested, are always sent to the originator of the requesting notification.

	WITH ATTRIBUTE-SYNTAX
		ConfirmationRequested
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
ConfirmationRequested ::= ENUMERATED {
	no-confirmation-requested (0),
	single-confirmation-requested (1), - - confirmation only from the user ACC-SA
	multiple-confirmation-requested (2) - - confirmation from all ACC-SA-s acting on the request
}
No confirmation-requested is necessary for notifications like memberlist-finder, which are meaningless without a response.
8.17.4.	
This attribute indicates that the user is waiting at his terminal for the confirmation. If this attribute is given when a request is forwarded from one ACC-SA to another, this indicates that, if possible, the response should be sent in the response to the forwarding operation which forwards the request.

	WITH ATTRIBUTE-SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
8.17.5.	
The triggerd-by attribute is mandatory in a notification which is in response to another notification, because this notification reports the result of actions requested in the other notification. It gives the ID of the notification to which the triggered notification is a response.

	WITH ATTRIBUTE-SYNTAX
		AccObjectDescriptor
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
This table shows the occasions where the triggered-by attribute are used:
Triggering notification	Resulting notification, with “triggered-by” to the triggering notification.	
Subscription-change	Acc-membership-decision (to the member) and confirmation (to the requestor)	
Memberlist-finder	Memberlist-report	
Update-distribution	Confirmation	
Object-inhibitor and object-burner	Confirmation (only for master-copy-distributed activities, sent from the master ACC-SA)	
Attribute-adder and attribute-subtractor	Confirmation (only for master-copy-distributed activities, sent from the master ACC-SA)	
Activity-announcement	Confirmation (only for master-copy-controlled activities, sent from the master ACC-SA)	
8.17.6.	
The following MHS notifications are available in computer conferencing too as follows:
MHS notification	Availability and use in computer conferencing	
, 
, as defined in X.411.

	(1)	Used when a contribution is sent via the MTS to the group activity to indicate to the originator whether the contribution was delivered to the group activity to which it was sent or not.
(2)	Used when a contribution is sent via the MTS from the group activity to its members, to indicate to the group activity service agent whether the contribution was delivered to the group member or not. The group activity service agent may provide this information in summarized form to its manager or members, using the AC-correlated-report-list as defined in X.413.
For activities with master-copy-membership-handling, delivery and non-delivery notifications are sent to the master ACC-SA, which will then forward them to the managers of the activity.
For activities which do not have master-copy-membership-handling, delivery and non-delivery notifications are sent to the ACC-SA from which the contribution was sent to the recipient. This ACC-SA will then forward these notifications to its local service manager.
Delivery and non-delivery notifications can also be forwarded to the contributor according to the policy of the activity, in similar ways as for distribution lists as defined in X.411.	
, as defined in X.420.	Used to indicate to the originator when a contribution was received by the individual members of group activities to which it was sent. Always sent to the originator.	
MHS notifications are stored and handled in ACC-SA-s in the same way as in the MS as specified in X.413.
8.17.7.	
An attribute-adder refers to another ACC Object, and adds additional attributes to it. The only attributes which can be added are, in this version of X.acc, keywords.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
		SET OF Keyword - - as defined earlier
	}
	MAY CONTAIN {
	}
	::= { accc-class-attributeAdder}
Within an attribute-adder, apply-to refers to the object, to which the attributes are added.
8.17.8.	
An attribute-subtractor refers to another ACC Object, and subtracts attributes to it. The only attributes which can be subtracted are, in this version of X.acc, keywords.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
		SET OF Keyword - - as defined earlier
	}
	MAY CONTAIN {
	}
	::= { acc-class-attributeSubtractor }
Within an attribute-subtractor, apply-to refers to the object, from which the attribute is to be subtracted.
8.17.9.	
An object-inhibitor refers to another ACC Object, and makes that object appear as if it did not exist. It is a local matter to which extent a system may allow a user, on request, to be able to see inhibited objects. An inhibited object is liable to be purged after a certain retention-period.
Notes
•	If an inhibited object is a link in a conversational chain, a skeleton (see 8.5.12) will still appear in order not to break the chain.
•	The removal of contributions from activities by moderators is done by inhibiting the link from the contribution to the activity, not by inhibiting the contribution itself.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
	}
	MAY CONTAIN {
	}
	::= { acc-class-objectInhibitor }
Within an acc-object-inhibitor, apply-to refers to the object which is inhibited, status is defaulted to ABSENT, master-copy-controlled is defaulted to FALSE and non-modifyable is defaulted to TRUE. 
8.17.10.	
An Object-burner refers to another ACC Object, and causes information within that object to be physically erased from all active media. 
Note – However, if a burned object is a link in a conversational chain, a skeleton (see 8.5.12) is kept in order not to break the chain. This skeleton will not contain any attributes except the name.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
	}
	MAY CONTAIN {
	}
	::= { acc-class-objectBurner}
Within an acc-object-burner, apply-to refers to the object which is to be burned, status is defauled to ABSENT, master-copy-controlled is defaulted to FALSE and non-modifyable is defaulted to TRUE. 
8.17.11.	
A presence-report notification is sent, every time a member retrieves from or contributes to an activity, from the ACC-UA to the master ACC-SA to update the presence value in the membership link for this user. Presence reports are only produced for activities with master-copy-membership-handling. The downloading of a contribution from the user ACC-SA to the ACC-UA is not enough to produce a presence report, in cases where the contribution is stored in the ACC-UA but not shown to the user. The listing of new items in a particular activity is enough to produce a presence-report, but not the listing of all activities with news in them.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
	}
	MAY CONTAIN {
	}
	::= { acc-class-presenceReport}
The apply-to attribute of the presence-report gives the activity, for which presence is reported. The original-creation-time attribute of the presence-report gives the reported presence time. The creator of the presence-report is the member, whose presence is reported (even though the report may be generated automatically).
8.17.12.	
A subscription-change is sent to change the status of, or add a new member to an activity. It can also be used to withdraw from membership in an activity.
A subscription-change is sent to the computer conferencing service. This service will either grant the request automatically or forward it to the manager of the group activity for handling.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
		membership-action,
		membership-type
	}
	MAY CONTAIN {
		member-names-to-add,
		number-of-old-items-wanted
	}
	::= {acc-class-subscriptionChange}
Within an acc-subscription-change, apply-to refers to the group activity to which the subscription request refers.
Note – A participant who already is a member, can use the subscription-change to modify his membership-type or to modify the number-of-old-items-wanted. The new membership will (if accepted) replace the old membership, but will take over statisticial and other attributes from the old membership. Such request from an existing member will cause all old items requested to be made available as new to this participant. The subscription-change can thus be used by a member of an activity, who has lost old items, to retrieve them again.
8.17.12.1	
This attribute gives the names of the participants who are to be added or removed.

	WITH ATTRIBUTE-SYNTAX
		SEQUENCE OF ACCoObjectDescriptor DEFAULT acc-originator
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
8.17.12.2	
This attribute indicates how membership is to be changed.

	WITH ATTRIBUTE-SYNTAX
		MembershipAction
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}

	added-as-member(0),
	rejected-as-member(1),
	excluded-from-membership(2),
	no-action-taken(3),
	other(4) 
	}
8.17.12.3	
This attribute contains a reference to a role object, which is sent together with this notification, and which describes the role in which capacity the members are to be added or removed.

	WITH ATTRIBUTE SYNTAX
		ACCObjectDescriptor
	MATCHES FOR ACCO-EQUALITY 
	::= {acc-attribute-type 15}
8.17.12.4	
This attribute indicates that the new members should have approximately this number of old items, added to the activity before they became members of it, made available to them.

	WITH ATTRIBUTE SYNTAX
		NumberOfOldItemsWanted
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
::= SEQUENCE {
	numberlimit 	[0] INTEGER (0 .. MAX) DEFAULT MAX,
	timelimit		[1] UTCTime OPTIONAL - - as defined in X.208
}
When both a numberlimit and a timelimit is given, the most restrictive of the two limits will determine how many old items to send.
8.17.13.	
(subclass to Acc-notification)
A membership-decision tells a participant whether his/her application for membership has been granted. It is also sent to a participant whenever that participant has been made into a member of an activity or removed from membership of an activity. The following attributes are in addition to the common attributes for all notifications.
Within a membership-decision, apply-to refers to the activity for which membership is controlled, and triggered-by refers to the triggering subscription-change.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
		member-name
		membership-action-result
		role-given
	}
	MAY CONTAIN {
		membership-decision-reason
		number-of-old-items-provided
	}
	::= {acc-class-membershipDecision}
8.17.13.1	
This attribute gives the name of the participant affected.

	WITH ATTRIBUTE-SYNTAX
		AccObjectDescriptor
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
8.17.13.2	
This attribute indicates how membership is to be or has been changed.

	WITH ATTRIBUTE-SYNTAX
		MembershipAction - - as defined earlier
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
8.17.13.3	

	WITH ATTRIBUTE-SYNTAX
		MembershipDecisionReason
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
::= BITSTRING {
	automatic (0), activity-unknown (1), access-control-rejection (2), technical-error (3)
}
8.17.13.4	
This attribute contains a reference to the role object created for a new member. A copy of the object referred to in this attribute is also usually enclosed with the membership-decision.

	WITH ATTRIBUTE-SYNTAX
		membership-type - - as defined in clause %.%.%
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
Within role-given, apply-to refers to the activity to which the member is added, and notification-type gives the new role. A new role does not replace old roles, a participant can have several roles at the same time. To remove an old role, an inhibitor or burner on the old role-given is necessary.
8.17.13.5	
This attribute indicates how many old items will be sent to the new member.

	WITH ATTRIBUTE SYNTAX
		INTEGER (0 .. MAX) DEFAULT 0
	MATCHES FOR EQUALITY ORDERING
	::= {acc-attribute-type 15}
8.17.14.	
A memberlist-finder notification is used to retrieve a list of the members of an activity. Listing of members is only possible for activities, for which the member-list-available attribute is TRUE.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
	}
	MAY CONTAIN {
		only-one-member
		role-restrictor
		role-attribute-restrictor
		maximum-number-of-members
	}
	::= {acc-class-memberlistFinder}
In the memberlist-finder, apply-to refers to the activity whose membership list is requested.
8.17.14.1	
This attribute indicates that not all members are requested, only the membership status for one particular member is wanted.

	WITH ATTRIBUTE-SYNTAX
		AccObjectDescriptor - - the member whose membership status is wanted
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
8.17.14.2	Maximum-number-of-members
This attribute gives a maximum number of member reports requested.

	WITH ATTRIBUTE-SYNTAX
		INTEGER 
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
8.17.14.3	
This attribute indicates that only membership of certain roles are wanted

	WITH ATTRIBUTE-SYNTAX
		SET OF AccClassType
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
8.17.14.4	
This attribute indicates that only certain attributes about the memberships are wanted. The membership link object with its acc-class-type, link-from and link-to attribute is always returned.

	WITH ATTRIBUTE-SYNTAX
		RoleAttributeRestrictor
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
RoleAttributeRestrictor ::= BIT STRING {
	last-present-wanted (0)
	statistics-wanted (1)
}
8.17.15.	
A memberlist-report notification is returned as a response to a memberlist-finder.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
		membership-list
	}
	MAY CONTAIN {
		not-all-members-listed
		only-local-members-flag
		memberlist-error
	}
	::= {acc-class-memberlistReport}
In the memberlist-report, apply-to refers to the activity whose membership list is reported.
8.17.15.1	
This attribute includes the list of the members of the activity.

	WITH ATTRIBUTE-SYNTAX
		MembershipList
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
::= SEQUENCE OF EntryInformation
8.17.15.2	
This attribute indicates that less than all members of the activity is returned.

	WITH ATTRIBUTE-SYNTAX
		NotAllMembersListed
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
::= BIT STRING {
	restricted-by-maximum	(0) - - if a maximum number of members was exceeded,
	restricted-by-type		(1) - - only members of certain types are included,
	only-one-member		(2) - - only one member was requested
	only-local-members	(3) - - only members in the user ACC-SA are returned
}
8.17.16.	
This attribute indicates that no membership list can be found.

	WITH ATTRIBUTE-SYNTAX
		MemberlistError
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
::= ENUMERATED { no-error (0), activity-not-known (1) }
8.17.17.	
An update-distribution notification is sent by an ACC-SA to instruct another ACC-SA to start or stop forwarding items from a certain activity to one or more ACC-SA-s and/or other MTS recipients, such as MHS subscribers.
The originator of this notification is the name of the ACC-SA making this request. (The receiving ACC-SA may, for a master-copy-distributed activity, reject update-distributions coming from other than the master ACC-SA.)
An update-distribution may be used to organize the distribution of items for a certain activity in an efficient manner (see clause %.%.% about routing). It may also be used by an ACC-SA to start or stop downloading items from another ACC-SA to itself for a certain non-master-copy-distributed activity from a certain ACC-SA.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
		update-distribution-actions
	}
	MAY CONTAIN {
	}
	::= {acc-class-updateDistribution}
In the update-distribution, apply-to refers to the activity whose items are to be forwarded.
8.17.17.1	

	WITH ATTRIBUTE-SYNTAX
		UpdateDistributionActions
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
::= SEQUENCE OF {
	stop-distribution 			[0] BOOLEAN DEFAULT FALSE - - If FALSE, distribution is to 
							- - be started
	where-to-distribute		[1] SEQUENCE OF ACCObjectDescriptor - - Should only contain 							- - names of ACC-SA-s
	number-of-old-items-wanted	[2] NumberOfOldItemsWanted - - defined in clause %.%.%.
}
8.17.18.	
A routing-report-request can be sent to an ACC-SA from a participant or from another ACC-SA to find out which activities the interrogated ACC-SA has and where it routes them.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
	}
	MAY CONTAIN {
		activity-restriction,
		server-restriction,
		announcement-request
	}
	::= {acc-class-routingReportRequest}
8.17.18.1	
The activity-restriction, if present, reduces the routing report to only a report for the listed activities.

	WITH ATTRIBUTE-SYNTAX
		SEQUENCE OF AccObjectDescriptor
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
8.17.18.2	
The server-restriction, if present, reduces the routing report to only a report on distribution to the listed servers.

	WITH ATTRIBUTE-SYNTAX
		SEQUENCE OF AccObjectDescriptor
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
8.17.18.3	
The announcement-request, if present, indicates that announcements are wanted for all activities.

	WITH ATTRIBUTE-SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
8.17.19.	
A routing-report is sent in response to a routing-report-request. Access control may cause the sender of a routing-report to exclude certain activities from a routing-report. Activities whose distribution-area-list excludes the interrogating ACC-SA will not be reported.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
		routing-report
	}
	MAY CONTAIN {
		incomplete
	}
	::= {acc-class-routingReport}
8.17.19.1	
Routing-reports contain a list of other servers served by the reporting server, and of which activities are distributed from the reporting server to each served server.

	WITH ATTRIBUTE-SYNTAX
		RoutingReport
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
RoutingReport ::= SEQUENCE OF {
	activity		[0] AccObjectDescriptor - - names of activities available in this server
	sending-list	[1] SEQUENCE OF {
						[0] ACCObjectName,	- - of servers which gets this activity from
									- - this server
					},
	announcement	[2] ACCCodedObject OPTIONAL - - with the announcement of the activity,
									- - if requested and available
}
8.17.19.2	An ACC-SA sending a routing-report can report incomplete as false even though it has for access-control-reasons omitted certain activities from the report.

	WITH ATTRIBUTE-SYNTAX
		BOOLEAN DEFAULT FALSE
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
8.17.20.	
An confirmation notification is sent by an ACC-SA to confirm that it has received and will handle the request in a notification which it has received, and which is referred to in the triggered-by attribute of the confirmation.

	SUBCLASS OF acc-notification
	MUST CONTAIN {
		confirmation-report
	}
	MAY CONTAIN {
	}
	::= {acc-class-updateDistributionConfirmation}
In the confirmation, apply-to refers to the activity in which the action is taken, and triggered-by to the notification being confirmed.
8.17.20.1	C

	WITH ATTRIBUTE-SYNTAX
		ConfirmationReport
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
ConfirmationReport::= SEQUENCE OF ENUMERATED {
	will-do (0), cannot-find-activity (1), cannot-find-server (2), access-control-error (3), other-error (4)
}
8.17.21.	
An activity-announcement describes an activity to potential members. It may be entered as a contribution to other activities, so that members of those activities are made aware of the new activity.
ACC-SA-s which recieve activity-announcements may enter information from them into the directory, unless it is already there. If all ACC-SA-s have access to a common globally-interconnected directory system, then the activity-announcement need only be entered once into the directory. Some ACC-SA-s may use non-global directories local to one or some ACC-SA-s. In this case, the activity-announcement may have to be entered separately for each non-global directory space.
Note – The ACC service assumes that all directory systems use a global naming space, but that use of a global naming space need not imply a globally interconnected directory system.
Activity-announcements are also used by owners to distribute information about changes to the attributes of an activity.  For centrally-controlled activities, activity-announcement ar used by owners to instruct the master ACC-SA to modify the activity.
The formal-name of an activity should never be changed. The free-form-name may however be changed, for example to reflect a change of topic.

	SUBCLASS OF acc-activity AND SUBCLASS OF acc-item
	MUST CONTAIN {
		acc-announced-activity
	}
	MAY CONTAIN {
		acc-previous-announcement
		acc-moderators
		acc-managers
	}
	::= { acc-class-activityAnnouncement}
As is shown above, the activity-announcement has almost the same format as the activity object itself. When an activity-announcement is used to modify an activity, a complete set of new attributes is necessary, also those attributes whose values are not changed must be included.
FFS Alternative 1: Send a copy of the group activity object itself as announcement.
FFS Alternative 2: Select certain of the attributes from the group activity object, plus possible additional attributes, and put them into the announcement. The announcement should in that case contain the DN of the group activity object itself.
Problems: If the group activity object itself is sent as announcement, then the names of the moderator, administrator, owner and members are not included. 
Also, should information be included on whether the reader of the announcement is allowed to make himself a member of the activity? This is presently not in the group activity object as specified above.
FFS If we do not have globally interconnected directories, then the activity-announcement may serve to enter the new activity into a local directory???
8.17.21.1	

	WITH ATTRIBUTE-SYNTAX
		AccObjectDescriptor
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
8.17.21.2	
If this actvity has been announced before, then the acc-previous-announcement attribute refers to the latest previous announcement of the same activity.

	WITH ATTRIBUTE-SYNTAX
		AccObjectDescriptor
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
8.17.21.3	
This attribute gives a list of the present moderators of the activity. Note that this is for information only. To actually modify the set of moderators, new moderators and inhibits or burners on the old moderator links must be submitted.

	WITH ATTRIBUTE-SYNTAX
		SEQUENCE OF AccObjectDescriptor
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
8.17.21.4	
This attribute gives a list of the present managers of the activity. Note that this is for information only. To actually modify the set of managers, new manager links and inhibits or burners on the old manager links must be submitted.

	WITH ATTRIBUTE-SYNTAX
		SEQUENCE OF AccObjectDescriptor
	MATCHES FOR ACC-EQUALITY
	::= {acc-attribute-type 1}
8.17.22.	
FFS: Free input links were for further study according to the notes from the Hague meeting. Are they a kind of notification? (Priority = 1, June 1993)
9.	Asynchronous Conferencing 
FFS: Should chapter 9 be cut down, since the actual abstract operations are defined in chapter 11. Perhaps chapter 9 should not describe parameters of the functions in as much detail as is done now? (Priority = 1, June 1993)
9.1	
Asynchronous conferencing functions are grouped into three ports as shown in figure 1:

Figure %
Asynchronous Computer Conferencing 
The provides the functionality associated with members.
The provides additional functionality for managing an activity.
The provides functionality for administrating the conference service and its group activities (e.g. creating and deleting activities, registering and removing participants and adding and removing group activity owners and administrators).
This grouping of functions provides general guidelines as to the capabilities of the above roles but is not binding. Final capabilities will be determined by the access control mechanism. 
For time-consuming functions, the requestor should be able to request that the function is performed in background, and the result returned via a notification.
The name of the requestor, and the date-time when the function was submitted to the ACCS, are implicit parameters to all functions.
In the following specification, each function is described by a prototype giving its name, formal parameters and result type. Formal parameters are represented by a data type followed by a parameter name. Prototypes are written in the following way:
function-name(type1 name1, ..., typeN nameN) -> result type
Note – The first parameter of all functions is the name of the participant invoking the function.
ACCname - the ACCObjectName of an object
ACCnames -  a set of ACCObjectNames
Object -  an object (including name and attributes)
Attribute - an attribute type and value
Attributes - a set of attributes
Types - a set of attribute types
Filter - a search pattern made up from a combination of attributes
Mods - a set of modifications to attributes
Status - indication of success/failure + relevant errors
Activity-role-type - Role
Role-type is a Link-type representing a role as defined above.
9.1.1	Member port
(ACCName of participant, ACCName of base-activity, Integer depth, Filter selection) -> ACCNames/Status
Search all group activities for those matching specific criteria as expressed by the filter. Searches all sub-activities of the base activity down to the specified depth (this allows searching within an activity hierarchy). Returns the ACCNames of the activities found.
If no base activity is given, the search is performed on all activities known to the user ACC-SA. Activities not known to the user ACC-SA are not scanned, unless they can be found in the directory.
FFS: It should be possible to make a search restricted to the subset of objects found by the preceding search. (Priority = 1, June 1993)
FFS: A participant should be able to find which activities another participant is a member of. This is however restricted to open activities, to closed activities in which they are both members, and to restricted activities which they may both make themselves a member of. How this modifies the function defined above is FFS. (Priority = 1, June 1993)
(ACCName participant, Filter selection, only-with-news) -> ACCNames/Status
Search the group activities to which the participant subscribes for those matching the filter. Return the ACCNames of the activities found, the type of membership, and for each activity, the number of non-processed contributions and the number of non-processed notifications within that activity. If no filter is given, all activities to which the particpant subscribes are returned. This function can only be performed by a participant on his own membership list. Whether users can look up the list of subscriptions for each other is beyond the scope of this recommendation | international standard.
If only-with-news is true, only those activities which have non-processed items or contributions for this user is returned.
Note: The total number of non-processed contributions can be less than the sum of the number of non-processed contributions for each activity, since the same contribution can appear as non-processed in more than one activity.
(ACCName participant, ACCName activity, Types targets) -> Attributes/Status
Return the values of the target attribute types from the N named activity. These may include purpose, membership and charging policies. All the attributes of an activity may be retrieved, subject to access controls. 
Statistics may also be returned if requested and available.
(ACCName participant, SubscriptionRequest) -> Status
Request for the named participant to become a member as specified by the SubscriptionRequest. The result indicates whether the request has been successfully noted. The request may then be lodged with the group activity administrator or may result in the ‘add-member’ function being invoked depending on the membership policy of the group activity. Unsubscribe is also performed by this function.
The subscription-request can include a request that the user wants to read old items from the activity, either by indicating that the N most recent old items are wanted, or that all old items with original-creation-date after a certain limit are wanted.
A person who is already a member of an activity can use the Subscription-request function to gain access to more old items. Such a Subscription-request will not make the person into a “double” member of the activity, but may cause more old items to be downloaded to the ACC-SA servicing that user.
(Unsubscribe has been removed, replaced by added functionality in the subscription-request function.)
(ACCName participant, ACCNames group activities) -> ACCNames/Attributes/Status
Return the ACCNames and selected attributes from group activities which have unread information on them for this participant. Also returns the number of new items on each group activity. Two numbers are returned, one for new contributions and another for new notifications. The user may optionally identify specific activities with the default being all activities to which the user subscribes.
Note – Because the same new contribution can appear on many activities, the sum of unread contributions across all activities may not be the same as the total number of unread contributions.
(ACCName participant, Filter selection, Types targets) -> ACCNames/Attributes/Status
Return the ACCNames and selected attributes from contributions which match the filter. The filter includes functionality for finding previously unseen contributions as well as contributions related to other contributions (e.g. ‘in-reply-to’).
Temporary comment: In X.acc, the restriction to only find contributions within one activity at a time was lifted in order to agree with the definition of the list operation in P7. A user can of course still restrict the search to a certain activity by a suitable filter (June 1993).
The filter should have the capability of checking for individual items in attributes which are lists, for example to find contributions which are replied-to by a certain other contribution.
The filter should also have the capability of selecting items on the value of the seen relation between the contributions and the requesting participant (FFS but not for anyone else??).
The group activity ACCName is optional and, if not supplied, defaults to all group activities to which the participant subscribes.
The function should support the following functionality:
•	Restrict search to items within a certain set of activities.
•	Restrict search to items contributed by specific participants.
•	Restrict search to items created/delivered between certain times.
•	Restrict search to items submitted/accepted/rejected to one or more indicated activities
•	Restrict search to a specific conversational branch in a group activity.
•	Find all contributions which are linked in a particular way to activities or contributions, for example finding all contributions which are in reply to another contribution.
	Note – Information about this is not available in the contributions, only in the link objects.
•	Limit results to a maximum number of contributions.
•	Order returned items by time forwards or backwards.
(ACCName participant, Filter selection, Types targets) -> ACCNames/Attributes/Status
Return the ACCNames and requested attributes from notifications which match the filter. Similar to find-contributions except that notifications, not contributions are found.
(ACCName participant, ACCName object, Types targets, Mark) -> Object/status
Returns the requested attributes from the named contribution or notification. The mark- parameter may be set to modify the value of retrieva-status as unchanged, listed or processed. The Read-item function is also used by the moderators to get submitted contributions. Only items available in the user ACC-SA can be read.
FFS: This is not compatible with P7. In P7, the retrieval-status is changed automatically depending on what you retrieve. Shall we be compatible with P7 here or not? (Priority = 2, June 1993)
(ACCName participant, ACCName item) -> Status
Changes the value of the retrieval-status between the requestor and the item.
FFS: This is not compatible with P7. In P7, the only explicit operation allowed on the retrieval-status is to change it from listed to processed. All other changes are only performed automatically. (Priority = 2, June 1993)
(ACCName participant, Object/ACCName new, ACCNames group activities, ACCNames reply-to, ACCNames obsoletes, ACCNames references, Keyword string, Request-for-acceptance-notification, Suppression-of-rejection-notification) -> status
Submit a new item to the named group activities. An entire new object may be supplied or the ACCName of an existing object may be given (for re-submission to new group activities). A contribution may be identified as replying-to, referencing or obsoleting other contributions. The result indicates whether the submission has been successfully registered in the system. 
The ‘group activities’, ‘reply-to’, ‘obsoletes’ and ‘references’ parameters are optional. FFS: Several questions remain to be answered about the effects of various combinations of these:
-	Is a new contribution which replies to an existing contribution and is not submitted to any explicit group activities  submitted to all group activities where the original is found?
-	If an existing contribution is re-submitted to new group activities are any replies to this contribution also submitted to these group activities?
Note – Modification of the text or the subject of a contribution can only be done by submitting an obsoleting contribution.
FFS: Who creates the submitted-to link? Is the name of this link returned as result? (Priority = 1, June 1993)
(ACCName participant, SubmissionWithdrawal) -> Status
This function is used to withdraw a submission, which has not yet been accepted by the moderator in a pre-moderated group activity. The returned status indicates that the SubmissionWithdrawal has been received by the ACCService.
(ACCName participant, Object/ACCName new, ACCName old) -> Status
Reply to the author of a contribution. The reply may be a new object or an existing object. The reply appears in the author’s workspace. Support for other IPM facilities is for further study as is anonymous reply.
(ACCName participant, ACCName contribution, Added attributes) -> Status
This creates a notification object, indicating that the contribution is to be modified.
Add-attribute is restricted to only certain attributes of contributions. Other attributes, like the subject and the text of a contribution, can be modified by writing an obsoleting contribution. The following attributes can be added to a contribution:
•	
Note – The contribution is not itself modified. Instead, an add-attribute is appended to it.
(ACCName participant, ACCName contribution, Removed attributes) -> Status
This creates a modification object, indicating that the contribution is to be modified by removing an attribute from it.
Remove-attribute is restricted to only certain attributes of contributions. Other attributes, like the subject and the text of a contribution, can be modified by writing an obsoleting contribution. The attributes which can be removed are the same as those that can be added in the Add-attribute function.
Note – The contribution is not itself modified. Instead, a remove-attribute is appended to it.
(ACCName participant, Link-object) -> Status
Used to submit a link.
(ACCName participant, ACCName item, ACCName activity/workspace) -> Status
Used to remove items from various domains. Items may be contributions or notifications or links. Domains may be group activities, personal or role workspaces. Thus, this function can be used to remove a contribution from a specific group activity, a notification from a personal workspace or a notification from a shared role domain (e.g. a moderator). The right to remove items is subject to access control. Items are removed by affixing an inhibit-item to the link linking the object to the domain.
The status only indicates that the function has been submitted, the actual removal will later be confirmed by a notification.
(ACCName participant, ACCName item, Burn) -> Status
Delete a contribution or notification object. Deleted items are removed from group activities and workspaces. Removal from personal workspaces is a matter of local policy. A skeleton (see 8.5.12) of the deleted item may be kept so as not to unhinge conversational structures. If Burn is TRUE, the object is physically erased, otherwise, it is deleted by affixing an inhibit object on it.
FFS: Access control on deletion? Can you delete everything you have created? (Priority = 1, June 1993)
(ACCName participant, ACCName member-to-be-found OPTIONAL, ACCName activity, Activity-role-type role) -> ACCNames/Status
Return the ACCNames of participants playing the specified role in the named group activity. If ACCName member-to-be-found is given, a search is only made for whether this participant is a member.
(ACCName participant, ACCName participant, Types targets) -> Attributes/Status
Returns attributes describing the named participants. It may be possible to request various types of information including
	• last access time,
	• activity memberships,
	• description and
	• statistics.
FFS: All attrtibutes subject to access controls? (Priority = 1, June 1993)
(ACCName participant, ACCName activity, ACCName member, Types targets) .> Attributes/Status
Returns attributes belonging to the link between a certain participant and a certain activity, such as last-active-time.
(ACCName participant, ACCName participant, Mods changes) -> Status
Modify the personal profile of the named participant.
(ACCName participant, ACCNames group activities) -> Objects/Status
Return all non-processed (=unseen) objects (complete)  from the specified group activities. The group activities parameter is optional and defaults to all group activities to which the participant subscribes. This function is like a combination of find-contributions and ACC-Fetch for all non-processed information on a given set of group activities. An important use of this function is to download objects into user agents for further local procesing.
9.1.2	Moderator port
(ACCName participant, ACCName activity, Filter selection, Types targets) -> ACCNames/Status
Return the ACCNames and selected attributes from contributions submitted to the moderator which match the specified filter. It is possible to request only items with a certain value of the retrieval-status attribute.
(ACCName participant, ACCName submission) -> Status
Accept the specified submission. This has the effect of including it in the group activity.
(ACCName participant, ACCName submission, Object notification) -> Status
Reject the specified contribution and create the supplied notification for the author.
Accept and reject are first sent by the moderator to the activity, and are then resent by the activity to the originator of the accepted/rejected contribution.
(ACCName participant, ACCName contribution) -> Status
All obsoleted contributions are deleted and replaced by the contribution referred to in the collapse function.
Note: The removal of contributions from activities by moderators is done by inhibiting the link from the contribution to the activity, not by inhibiting the contribution itself.
9.1.3	Conference Management Port
(ACCName participant, ACCName activity, Attributes description) -> Status
Create a group activity with the given ACCName and description. The ACCName may indicate that the new group activity is a sub-group activity of an existing one.
(ACCName participant, Object announcement, ACCNames activities) -> Status
Submit an announcement contribution for a new group activity to the named group activities. One of the attributes of the announcement will be the ACCName of the new group activity.
(ACCName participant, ACCName activity) -> Status
Suspends the function of a group activity but does not remove its information from the service. Users will be informed of the suspension of the group activity.
(ACCName participant, ACCName activity) -> Status
Delete the group activity from the system and notify members.
(ACCName participant, ACCName member, ACCName activity, Activity-role-type role) -> Status
Add the named member to the group activity playing the specified role and notify the new member. Existing other roles for this member in the activity are not changed.
(ACCName participant, ACCName member, ACCName activity, Activity-role-type role) -> Status
Removed the named member from the given role in the group activity and notify the removed member. Existing other roles for this member in the activity are not changed.
(ACCName participant, ACCName request, Object notification) -> Status
Reject a request for membership and notify the participant.
(ACCName participant, ACCName activity, Mods changes) -> Status
Update the group activity description and policies (e.g. expiry times and other policies). The free-form-name of an activity can be changed with the modify-group-activity operation, but the formal-name should never be changed.
(ACCName participant, ACCName new-participant, Attributes profile) -> Status
Register the new participant as a participant in the service, or to modify the registration attributes.
(ACCName participant, ACCName participant) -> Status
Remove the named participant from the service.
FFS: Routing: (Excerpt from the minutes of the Tokyo 1993 meeting): We had a long discussion about distribution and routing in computer conferencing. In a large system of widely distributed ACC-SA-s, how is it decided which SA-s are to route contributions belonging to a particular activity? Should this be controlled and organized by a central route organizer, or should every ACC-SA-s make the necessary routing arrangements for its needs? Should information about which activities are available be given between ACC-SA-s through the ACC-SA-ACC-SA-protocol, or should such information be available from the Directory System? Should there be special “ADMD” ACC-SA-s serving as central focal points of routing to more peripheral “PRMD” ACC-SA-s? (Priority = 1, June 1993)
9.1.4	This clause, numbered 9.6 in X.acc | ISO/IEC 10021-acc version 11 was removed in June 1993
9.1.5	More about notification handling
FFS Is there a need for separate receipt notifications for each body part??? (Priority = 1, June 1993)
FFS Should there be tailored additional notifications for special applications, for example “I agree” or “I disagree”. (Priority = 1, June 1993)
9.1.6	Issues for further study:
What information can a member of a group activity find out about other members, e.g. how far they have read, how much they have read and written etc. (Priority = 1, June 1993)
Advanced facilities like voting and joint editing. (Priority = 2, June 1993)
Can objects in general have four states: Active, In Modification, Frozen (=Write-protected), Suspended? (Priority = 1, June 1993)
Which notifications are needed and how will they be used? (Priority = 1, June 1993)
Are "alerts" supported? (Priority = 1, June 1993)
What is contained in a group activity description? (Priority = 3, June 1993)
How are objects named? In particular:  Are contributions named by the originating ACC-SA or by the activity to which they are contributed?
How are requests for new activities generated? (Priority = 1, June 1993)
It should be possible, for each ACC-SA, to define rules on who may start new activities of different kinds. (Priority = 2, June 1993)
How are keywords set on activities? (Priority = 1, June 1993)
Can "filter" objects be stored and then activated? They deliver their results to a single user, to an activity or to a moderator. What about messages adressed to "anyone" combined with filters to select on them? (Priority = 1, June 1993) Editor’s suggestion: Not in this standard now.
What service controls are there (e.g. cost, size etc.) The possibillity to charge sender, manager or recipient should all exist. Credit should also be possible (e.g. that the recipient pays the sender for what s/he writes). (Priority = 1, June 1993) Editor’s suggestion: Do not include!
What support is needed for forms and semistructured messages, and how? (Priority = 1, June 1993) Editor’s suggestion: Not in this standard now.
What facilities are needed for the delegation of authority? Can links be used for this? (Priority = 1, June 1993)
10.	
10.1	
10.1.1	Partitioning
The ACCS is implemented by a set of ACC-SA-s. Each ACC-SA may controls one or more activities for which acc-master-SA is set.
It is a property of each group activity whether it is centrally controlled or not. A master-copy-controlled activity is controlled by one ACC-SA which holds its master information. Other ACC-SAs may hold copies of information from the activity which enable them to carry out certain retrieval operations locally. All changes to the group activity information must however be done via changes in the master copy, handled by the master ACC-SA.
For an activity which is not master-copy-controlled, an operation changing the activity can be performed on any copy of the activity (subject to access control). Some such changes are then transmitted to all other copies of the activity, some changes may affect only the local copy of the activity. For example, for an activity without master-copy-membership-handling, each local copy holds a list of local members and there is no central list of all members of the activity anywhere.
A master-copy-distributed activity, is an activity where all new items within the activity must be distributed via the master ACC-SA for that activity. Pre-moderated activities must be master-copy-distributed.
FFS: Really??? (Priority = 1, June 1993)
A master-copy-membership-handling activity, is an activity where all changes to its membership list must be approved by the master ACC-SA.
An activity can be master-copy-controlled but still not master-copy-distributed. This means that all changes to the activity attributes, like the type of the activity, is master-copy-controlled, but that new contributions can be input to any copy of the activity (subject to access control).
10.1.2	
10.1.2.1	Operational procedure
The most general model of the execution of operations on master-copy-controlled activities defines two phases:
•	A navigation phase, where operation is directed to a suitable ACC-SA.
•	An execution phase, where this ACC-SA coordinates its execution.
Different modes of ACC-UA – ACC-SA and ACC-SA – ACC-SA interaction are possible including ‘chaining’ and ‘Referrals’, as defined in the Directory System (DS). This document adopts a chaining model, as this is the more general case (requiring an ACC-SP version of most operations). Referral solutions can be derived from this.
10.1.2.2	Navigation

Figure %

Navigation (see Figure %) involves:
(1)	A ACC-SA receives an operation from an ACC-UA.
(2)	The initial ACC-SA uses the directory to locate the target ACC-SA.
(3)	The initial ACC-SA chains the operation to the responsible ACC-SA.
10.1.2.3	Execution
After navigating to the responsible ACC-SA, this will then execute the operation:
(4)	The responsible ACC-SA executes the operation, which may involve the use of DS, MHS, DFR and other underlying services.
Notes
(a)	Some operations can always be performed by the initial ACC-SA (e.g. listing subscriptions) as they only require DS access.
(b)	Some operations may be chained using the MHS, some may be more suitable for ROS.
The execution phase may involve an ACC-SA coordinating access to the Directory, local DFR and other ACC-SAs (sing ROS or MHS based ACC-SP operations). This is shown in Figure 3. 
Note – This figure does not show the chaining of the operation, this was already done in the navigation phase. But more than one ACC-SA may be involved in the execution of an operation, for example distribution of a contribution via nested distribution lists.

Figure 3

10.1.2.4	
Access control on operations requested by a user might be performed at three stages:
UA access control: By the ACC-UA through which the operation is generated.
Local SA access control: By the ACC-SA to which this ACC-UA submits the operation.
Responsible SA access control: By the ACC-SA responsible for execution of the operation.
Owner or moderator control: By the owner or moderator of the activity on which the operation is to be performed. (Examples: Contributions to pre-moderated activities, admission of new members to closed activities.)
Primary responsibility for access control lies with the responsible ACC-SA. It is the responsibility of this ACC-SA to enlist the aid of the owner or moderator of the accessed object when necessary.
FFS: How? No protocol is defined for enlisting this aid! (Priority = 2, June 1993)
The local ACC-SA is responsible for checking the identity of the user, enlisting the help of the ACC-UA. The local ACC-SA and the ACC-UA may also perform preliminary access control of the operation, but this access control should then be re-checked by the responsible ACC-SA.
10.1.3	

Figure %

Dashed lines indicates offers of distribution which are turned down
because the receiving ACC-SA already has got the offered object.
An operation on a non-master-copy-controlled activity can be performed on any copy of the activity. For some operations, the result is then distributed to all other copies of the activity in other ACC-SAs.
This may of course result in clashes between contradictory operations performed simultaneously on different local copies of an activity. However, if the frequency of operations causing such clashes are low, this can be accepted.
10.1.3.1	
Primary responsibility for access control lies with the local ACC-SA to which an operation is first submitted. Other ACC-SA-s may also perform access control, but since the result of the operation becomes available as soon as the operation has been accepted by the local ACC-SA, primary responsibility must be with that ACC-SA.
10.1.4	
Asynchronous Computer Conferencing Service Agents may locally within a company communicate via direct ROS-based operations or in wider areas via underlying services like MTS and DS. In general, the communication between ACC-SA can work as shown by figure %.

Figure %

An ACC-SA may communicate with another ACC-SA either via ROSE or via MTS or in both ways.
Figure % shows two Companies communicating in different ways. This figure shows that also the Directory System (DS) can be used for some of the communication between ACC-SA-s. 
Note – Since DFR is not a distributed service, communication between DFR stores must be handled indirectly via the ACC-SA-s they are serving.

Figure %

10.1.5	
10.1.5.1	Distribution for a 
Figure 5 shows the distribution of Asynchronous Computer Conferencing information when it has been submitted to the ACC-SA responsible for this activity:

Figure 5

Figure 6 shows the distribution of Asynchronous Computer Conferencing information when it has been submitted to another ACC-SA than the one responsible for this activity:

Figure 6

Question 1: Does this mean that we are not permitting the Usenet News type of flooding for distribution of news?
Question 2: What about a message which was submitted by an IPMUA to an MTA?
10.1.5.2	Distribution for an 
Contributions for a non-master-copy-distributed activity can be input to any copy of the activity. The contributions are then copied from that activity to neighboring activities, and from them to further neighboring activities, until they have percolated to all copies of the activity everywhere. Loop control is used to stop the same contributions from entering a copy of an activity more than once. In order to avoid ineffective duplicate sending, each service agent may first receive a list of new objects, and then check which of the objects it already has, and then download only those it does not already have.
This method of distribution can be likened to the pouring of water on a flat surface, where the water spreads in all directions.
Figure % gives a pictorial view of this distribution process.

Figure %

Dashed lines indicates offers of distribution which are turned down
because the receiving ACC-SA already has got the offered object
10.1.6	Varying real implementations
The real implementations of Asynchronous Computer Conference systems may map into this architecture in different ways, as shown in figure 7, 8 and 9:
Implementation 1: UA with co-located single-user store, see figure 7.

Figure 7

Implementation 2: Integrated multi-user system with internal store, see figure 8.

Figure 8

Implementation 3: Integrated multi-user system without internal store, see figure 9.

Figure 9

10.1.7	(moved to 10.2.)
10.1.8	Purging
ACC-SA-s may purge objects in order to control the size of their object stores. Purging policies are defined locally, but it is recommended that the following guidelines are followed:
(1)	If a contribution is purged, which has other contributions referring to it, then a skeleton (see 8.5.12) should be kept.
(2)	If an object has an expiration time, do not purge it before the end of this time.
(3)	Purge inhibited objects, which have been in the inhibited state for the retention period, before other objects.
(4)	Do not purge links until the linked objects are purged.
(5)	Do not purge notifications until the objects they apply-to are purged.
(6)	Keep activitity objects and activity announcements longer than other objects.
10.1.9	For further study
Support for the Message Store is FFS (Priority = 2, June 1993)
10.2	
Every asynchronous computer conferencing server should be co-located with an inter-personal messaging server as defined in X.411| ISO/IEC 10021-4, X.413 | ISO/IEC 10021-5 and X.420| ISO/IEC 10021-7. Every asynchronous computer conferecing participant should also be an IPM user and have an MHS OR-name.
Rationale: This is necessary in order to allow personal replies to be written on group communication contributions, which is a required functionality. If this is not provided, we will have to repeat a personal messaging service within asynchronous computer conferencing, which is obviously not desirable.
Asynchronous computer conferencing can co-work with MHS in the following ways:
(a)	ACC may use MTS to transport objects between ACC-SA-s.
(b)	Each ACC-UA must also be an MHS-UA, so that recipients of contributions can send personal replies only to the contributor.
(c)	MHS-UA-s may be allowed to submit contributions to ACC activities. The activity will then look like a distribution list to such UA-s. If DL-expansion-prohibited is set on an MHS contribution, the ACC service will refuse to handle it.
(d)	MHS-UA-s may be members of ACC activities and receive contributions from them. The MHS-UA may be a member of the copy of the activity in any ACC-SA which holds a copy of this activity. The activity will then look like a distribution list to such UA-s. 
An ACC-SA may combine several contributions as separate body parts in a combined message when forwarding them. Such a composite message is called a digest.
For co-working of type (c) and (d) above the following applies:
(i)	Access controls on an activity may or may not allow MHS-UA-s to submit and receive contributions via the MTS.
(ii)	What is written about MHS-UA-s also applies to telematic access units for fax, voice or physical delivery.

10.3	
10.3.1	Member port abstract user functions
10.3.1.1	
The find-activities abstract user function is performed by issuing an ACC-List operation from the ACC-UA to its ACC-SA. The user ACC-SA will scan its local store of information about activities. It may also chain the operation along to the directory. It is not required that it issues an operation on other ACC-SA-s to find the requested information.
10.3.1.2	
The find-subscribed-activities abstract user function is performed by issuing an ACC-List operation from the ACC-UA to its ACC-SA. Only information available in the user ACC-SA is returned, so no SA-SA operation will be performed.
10.3.1.3	
The describe-activity abstract user function causes an ACC-Fetch operation to be performed from the ACC-UA to its ACC-SA.
10.3.1.4	
The Subscription-request abstract user function is issued by the ACC-UA sending a subscription-change notification, using the Acc-submit abstract operation, to its  ACC-SA. It is then handled by the user ACC-SA in the following way:
•	The ACC-SA checks if the activity is known to it. It may connect to the directory in doing this.If the activity is not found in the directory either, a membership-decision indicating an activity not known error is returned.
Procedure for master-copy-distributed-controlled activities:
•	If the user ACC-SA is the master of this activity, access control is performed, the list of members is updated and the items within the activity are made available to the new subscriber.
•	If the user ACC-SA is not the master of this activity, the subscription-change is forwarded to the master ACC-SA using a forward-item operation. The master ACC-SA will then perform access control, update the list of members, and send a membership-decision notification back to the user ACC-SA. The master ACC-SA will also ensure that (none, some or all) old items are sent to the user ACC-SA (using the forward-item operation) and that future items are sent to the user ACC-SA (by sending them itself, or instructing another SA to send them by sending an update-distribution notification to them).
Procedure for non-master-copy-controlled activities:
•	If the activity is already available, the local membership list is updated and items are made available. If necessary, an update-distribution notification is sent to get another ACC-SA to send items in the activity to the user ACC-SA.
When a subscription-change has been accepted or denied, a membership-decision notification will also be sent to the requestor, informing him/her of the outcome of the request. This notification should preferably be sent before sending any old items from the activity to the requestor (so that the ACC-UA will be able to handle these items as entries in an activity in which the user is a member). Membership-decisions can also be sent to report membership-decisions taken for other reasons than a subscription-change, such that distribution for technical reasons must be discontinued.
10.3.1.5	
The List-News abstract user function is performed in the same way as a find-subscribed-activities abstract user function with the only-with-new flag set to TRUE. For more information, see the description of the find-subscribed-activities function above.
10.3.1.6	
The find-contributions abstract user function is performed by issuing an ACC-List operation from the ACC-UA to its ACC-SA. There is no requirement to look for contributions elsewhere than in the storage of the user ACC-SA.
10.3.1.7	
The find-notifications abstract user function is performed by issuing an ACC-List operation from the ACC-UA to its ACC-SA. There is no requirement to look for notifications elsewhere than in the storage of the user ACC-SA.
10.3.1.8	
The read-item abstract user function is performed by issuing the ACC-Fetch abstract operation (see %.%.%). The ACC-SA will look up the requested item in its store. There is no requirement to look for items elsewhere than in the storage of the user ACC-SA.
The selector choice of the Fetch argument can be used to find the item with a certain ID. If the UA knows the sequence number in the ACC-SA of the item to be fetched, the precise choice can be used.
If the item cannot be found in the store of the user ACC-SA, a not-found error is returned.
The read-item abstract user function cannot be used to fetch an item which has to be retrieved from another ACC-SA. To read such items, a subscription-change notification can be sent to the activity to which the item to be fetched belongs. Such a subscription-change notification may then cause items belonging to this activity to be copied to the local ACC-SA, so that the UA can retrieve them. A way for an ACC-SA to get old items down-loaded from one ACC-SA to another is to send an update-distribution notification.
Note – subscription-change, requesting someone who already is a member to become a member again, is sometimes useful to get old items within the activity downloaded to the member.
10.3.1.9	
The mark abstract user function is performed by issuing an ACC-Fetch abstract operation which fetches nothing, only changes the retrieval-status value.
10.3.1.10	
The submit-item abstract user function creates one or more new items. It is performed by issuing the Acc-submit abstract-operation from the ACC-UA to the ACC-SA.
Note that the forwarding of an existing contribution to an additional activity may entail the submission only of a link object, not of any new contribution object.
If the new items are submitted to a non-master-copy-distributed activity, they are added to the store of the user ACC-SA and forwarded with the forward-item operation to other ACC-SA-s who have asked to get items in this activity forwarded to them.
If the new items are submitted to a master-copy-distributed activity, they are not immediately added to the store of the user ACC-SA (unless it is the master ACC-SA). They are instead forwarded with the forward-item operation to the ACC-SA responsible for this activity, and this ACC-SA will then ensure distribution of the new items to all ACC-SA-s with subscribers to this activity.
The forward-item operation will, when an already existing contribution is forwarded to a new activity, forward the existing contribution together with the new link.
10.3.1.11	
The withdraw-submission abstract user function is performed by issuing an Acc-submit operation, sending an object-inhibitor notification (see clause %.%.%) from the ACC-UA to its ACC-SA. This object-inhibitor can either inhibit the submission itself, or it can inhibit the link from the submission to the activity. The latter is preferable, if the originator wants to send the submission to some other activity, of if the submission had already been submitted to another activity. Note that when the originator is different from the submitter, the submitter is usually only allowed to inhibit the link from the contribution to the activity, not the contribution itself. The user ACC-SA will forward the object-inhibitor notification, using the forward-item operation, to the ACC-SA responsible for the activity, which will then forward it to the moderators.
10.3.1.12	
The personal-reply abstract user function is realized by the sending of an IPM reply (as defined in X.420) through the MTS to the originator of the replied-to contribution.
10.3.1.13	
The add-attribute abstract user function is realised by issuing, from the ACC-UA to the ACC-SA, an Acc-submit operation, submitting an attribute-adder (defined in clause %.%.%). The attribute-adder is forwarded as described for submit-item above.
The apply-to attribute of the attribute-adder contains the name of the item, to which the attribute is to be added. The acc-keywords attribute contains the added keywords.
10.3.1.14	
The remove-attribute abstract user function is realised by issuing, from the ACC-UA to the ACC-SA, an Acc-submit operation, submitting an attribute-subtractor (defined in clause %.%.%). Such attribute-subtractors are forwarded as described for submit-item above.
The apply-to attribute of the submitted notification contains the name of the item, from which the attribute is to be removed. The acc-keywords attribute contains the removed keywords.
10.3.1.15	
The add-link abstract user function is realised by issuing, from the ACC-UA to the ACC-SA, an acc-submit operation, submitting a notification identical to the new link. Such notifications are forwarded as described for submit-item above.
10.3.1.16	
The remove-link abstract user function is realised by issuing, from the ACC-UA to the ACC-SA, an Acc-submit operation, submitting a notification of type object-inhibitor or object-burner, to delete the link to be removed. Such notifications are forwarded as described for submit-item above.
10.3.1.17	
The delete-object abstract user function is realised by issuing, from the ACC-UA to the ACC-SA, an Acc-submit operation, submitting a notification of type object-inhibitor or object-burner. Such notifications are forwarded as described for submit-item above. Access control in each ACC-SA and ACC-UA receiving the inhibitor/burner may restrict whether the copy of the object in that ACC-SA/ACC-UA will actually be performed.
10.3.1.18	
The find-members abstract user function is realised by the ACC-UA issuing an Acc-submit operation to the user ACC-SA, submitting a memberlist-finder notification. As a result, the ACC-UA will receive a memberlist-report notification back, either in the response to the Acc-submit operation or as a separate notification at a later time.
If the user ACC-SA cannot find any information about the existence of the activity (in its store, or by using the directory) the ACC-SA will return an activity-not-known error in the memberlist-report notification.
If the member-list-available attribute of the activity is FALSE, then a member-list-not-available error is returned in the memberlist-report notification.
If the activity does not have master-copy-membership-handling, the user ACC-SA will return only a list of the local members, with the only-local-members bit set in the memberlist-report notification.
If the activity has master-copy-membership-handling, then the memberlist-finder is forwarded, using the forward-item operation to the master ACC-SA. The master ACC-SA will then return the list of members to the user ACC-SA  in a memberlist-report which is then forwarded it to the ACC-UA.
10.3.1.19	
The describe-participant abstract user function is performed by the ACC-UA issuing an ACC-fetch abstract operation to the ACC-SA for the requestor. This ACC-SA will look for the information in its local store, and may use the directory to find the information elsewhere, but need not try to get the information from other ACC-SA-s other than via the directory. 
10.3.1.20	
The Describe-member abstract user function is performed in the same way as the find-members user function described above, with only-one-member referring to the member whose description is requested.
10.3.1.21	
The modify-profile abstract user function is performed by the ACC-UA issuing an ACC-register operation to its ACC-SA. The ACC-SA may store some or all of the registered information in the directory.
10.3.1.22	
The download-news abstract user function is performed by the ACC-UA issuing an ACC-list abstract operation to its ACC-UA, such that all new items in all activities are requested. Note that this differs from the message store (MS) retrieval protocol defined in X.413.
FFS: This is not the way List in MS was meant to be used. List in MS is restricted to only a limited set of attributes, in particular not including the content! (June 93) (Priority = 1, June 1993)
10.3.2	Moderator port abstract user functions
10.3.2.1	
The find-submissions abstract user function is performed by the ACC-UA issuing an ACC-list or ACC-fetch abstract operation with a suitable selector, in which link-choice has the activity, whose submissions are to be found, as starting-point, following the submission-link-arcs.
(The submission-links are created by the responsible ACC-SA when receiving submissions. See %.%.%.)
The moderator ACC-UA need not be connected to the master ACC-SA for the moderated activity, since the submissions will be forwarded to the moderator ACC-SA if necessary. If the moderator is not connected to the ACC-SA controlling the activity, the moderator can forward operations to this ACC-SA embedded in MTS messages.
10.3.2.2	
The accept and reject user functions are realised by the moderator creating an accepted-contribution or rejected-submission link (see clause %.%.%) and sending it to the ACC-SA responsible for the activity. This ACC-SA will then distribute this link to the other moderators, and, if the submission was accepted, to the members of the activity, together with the accepted contribution itself.
10.3.2.3	
The collapse user functions is realised by sending inhibit-object notifications (see %.%.%) on the older versions to be deleted. At the same time, replied-to-IPM, obsoleted-IPM and related-IPM links on the inhibited contributions are copied to the earliest non-inhibited version which is not to be inhibited.
10.3.2.4	
The ACC-SA, when receiving a request to create or modify an activity, will ensure that the activity gets an acceptable activity name. If this is not possible, the request is rejected.
The activity must get a globally unique directory name. This is ensured by the ACC-SA in one of two ways:
(i)	The ACC-SA uses the services of the directory system.
(ii)	The ACC-SA has allocated to it, a certain subtree within the global directory naming tree, and will create the name within the naming space spanned by this subtree.
If the group activity is to co-work with MHS, then the ACC-SA shall also ensure that the group activity gets a globally unique OR-address. This is done by registering the activity with a suitable MTS MTA.
10.3.2.5	
The announce-group-activity user function is realised by the submission, using the Acc-submit abstract operation, of an activity-announcement (see %.%.%). This is distributed in similar ways to contributions. To get a large distribution of an activity-announcement, it should be submitted as a contribution to activities with wide distribution. Such activities may have access control, letting them only accept activity-announcements and no ordinary contributions.
Activity-announcements are also distributed to existing and new members of the activity being announced. How this is shown to the members is not specified by this standard.
10.3.2.6	
The suspend-group-activity abstract user function is realised by the submission, using the Acc-submit abstract operation, of an activity-announcement modifying the activity attributes.
10.3.2.7	
The delete-group-activity abstract user function is realised by the submission, using the Acc-submit abstract operation, of an inhibit-object on the group activity itself.
10.3.2.8	
The add-member and remove-member abstract user function is realised by the submission, using the Acc-submit abstract operation, of a o subscription-change notification.
10.3.2.9	
The reject-subscription-request user function is realised by the submission of a membership-decision notification.
10.3.3	
10.3.3.1	
The modify-group-activity function is, when attributes of an activity are to be modifed, realised by the submission, using the Acc-submit abstract operation, of an activity-announcement.
To modify the links on an announcement, the Acc-submit abstract operation is used, submitting the new link objects, and/or submitting inhibit-object or burn-object notifications to remove links from the activity.
10.3.3.2	
The register-participant and unregister-participant user function is realised by the ACC-register abstract operation. Only ACC-UA-s connected to an ACC-SA can register participants in that ACC-SA.
10.3.3.3	
The routing abstract user function is realised by the sending, between ACC-SA-s, of update-distribution notifications.
In order to find information needed to optimize routing, an ACC-SA can interrogate which activities another ACC-SA has. This is done by sending routing-report-request notifications.
11.	Asynchronous Computer Conferencing Access Protocol (UA-SA protocol, ACCAP)
Temporary Note: All of this chapter is new in version 13. Much of the text has been adopted from the corresponding text in Draft CCITT Recommendation X.413 | ISO/IEC 10021-5:1994.
This chapter defines the protocol from a 
•	Asynchronous Computer Conferencing User Agents (ACC-UA) to a 
•	Asynchronous Computer Conferencing Service Agent (ACC-SA).
This protocol is called the Asynchronous Computer Conferencing Access Protocol (ACCAP).
An ACC-UA represents one user, and can connect to one specific ACC-SA. 
An ACC-SA can serve several ACC-UA-s.
Every ACC-UA is colocated with an MHS-UA. The MHS-UA is used to send personally addressed replies to ACC contributions.
Note - The protocol defined in this chapter is, intentionally, very similar to the corresponding protocol in X.413 | ISO/IEC 10021-5. The intention with this is to avoid duplication of effort by allowing implementors of X.acc | ISO/IEC 10021-acc and X.413 | ISO/IEC 10021-5 to use much of the same code.
11.1	
The ACCAP-Bind abstract-bind-operations binds the Member, Moderator and Conference Management ports of the ACC-user (consumer) to the ACC-service (supplier). The initiator is the ACC-user, while the responder is the ACC-service. Information exchanged in the argument and result of ACCAP-Bind shall apply for the duration of the abstract-association. ACCAP-Bind is defined as follows:
ACCAPBind ::= ABSTRACT-BIND
	TO {member[S], moderator[S], management[S]}
	BIND
		ARGUMENT	ACCAPBindArgument
		RESULT	ACCAPBindResult
		BIND-ERROR	ACCAPBindError
Note - The ACC abstract-service does not provide any explicit mechanisms to allow the same ACC-UA to have more than one simultaneous association with an ACC-SA. Where this is supported (as a local matter) it is the responsibility of the ACC-user to coordinate such invocations so that mutual interference is avoided (e.g., simultaneous invocations of modifying abstract-operations could fail or produce unintended results).
11.1.1	
The abstract-bind-argument parameters are used to identify, authenticate and set the security-context for an ACC abstract-service-user. They also contain a set of restrictions for entries to be returned as result of an ACC-Fetch abstract-operation, identify a set of registrations associated with the UA, and may contain a request to be informed of the attribute-types, matching-rules, message-group support and content-types to which the ACC-user has subscribed.
::= SET {
	initiator-name				ORName,
	initiator-credentials		[2]	InitiatorCredentials,
	security-context 			[3]	IMPLICIT SecurityContext OPTIONAL,
	fetch-restrictions			[4]	Restrictions OPTIONAL -- default is none--,
	content-specific-arguments	[7]	SEQUENCE SIZE(1..ub‑content‑specific) OF 
								ContentSpecificArgument OPTIONAL}
The parameters of the abstract-bind-argument have the same meaning as the corresponding arguments as defined in X.413 | ISO/IEC 10021-5. The jumps in the tag numbering is intentional to keep compatibility with X.413 | ISO/IEC 10021-5.
11.1.2	
::= SET {
	responder-credentials		[2]	ResponderCredentials,
	available-attribute-types		[4]	SET SIZE (1 .. ub-attributes-supported) OF 
								ATTRIBUTE.&id ({AttributeTable} OPTIONAL,
	content-types-supported		[6]	SET SIZE (1..ub-content-types) OF OBJECT 
								IDENTIFIER OPTIONAL,
	...	-- 1994 extension additions -- ,
	matching-rules-supported		[8]	SET SIZE(1..ub‑matching‑rules) OF OBJECT 
								IDENTIFIER OPTIONAL,
	content-specific-capabilities	[11]	SET SIZE(1..ub‑content‑specific) OF 
								ContentSpecificcapability OPTIONAL,
	service-information		[12]	GeneralString (SIZE(1..ub-service-information-length)) 
								OPTIONAL }
The parameters of abstract-bind-result have the same meaning as the corresponding arguments as defined in X.413 | ISO/IEC 10021-5. The jumps in the tag numbering is intentional to keep compatibility with X.413 | ISO/IEC 10021-5. FFS?? (Priority = 1, June 1993)
11.1.3	
An ACC-Bind-error reports a problem in attempting to establish an abstract-association.  It is identical to the corresponding operation in X.413 | ISO/IEC 10021-5.
11.1.4	
The ACC-Unbind abstract-unbind-operation is identical to the corresponding operation in X.413 | ISO/IEC 10021-5.
11.2	
This chapter defines the capabilities of the ACC abstract-service provided to an ACC-abstract-service-user at the Member Port, Moderator-port and Conference Management Port of the ACC-service. These capabilities are modelled as abstract-operations which may cause abstract-errors when invoked.
11.2.1	
This subclause defines a number of common data-types which are used in several of the abstract-operations defined in later on. The following common data-types are defined
a)	Range;
b)	Filter;
c)	Selector;
d)	Link-choice
e)	Entry Information Selection;
f)	Entry Information;
g)	ACC Submission Options.
11.2.1.1	
This attribute is defined identically to the corresponding attribute in X.413 | ISO/IEC 10021-5.
11.2.1.2	
This attribute is defined identically to the corresponding attribute in X.413 | ISO/IEC 10021-5, with the following exception in the definition av assertions within filter-items:
An assertion about the value of an attribute can be evaluated only if properly specified.  If the ACC does not support the attribute-type, or the presented attribute-value does not conform to the matching-rule's assertion-syntax, or the definition of the attribute-type does not include the type of match requested, then the abstract-operation which contains the assertion shall fail; the abstract-operation shall return an attribute-error.
11.2.1.3	
A selector parameter is used to select entries. The selection operates in four stages. Firstly, the total set of entries may be restricted to a particular contiguous set by specifying its range. Secondly, the selection may be restricted to only those objects which have a certain link-relation to an indicated object (for example all entries linked to an activity). Thirdly, entries from within this set may be selected by specifying a filter which the selected entry shall satisfy. Fourthly, a limit may be placed on the number of entries thus selected.  If the range is defined in ascending order (or is omitted), those entries with the lowest sequence-numbers are selected; if the range is defined in descending order, those entries with the highest sequence numbers are selected (see 8.1.1).  Abstract-operations are applied to selected entries according to their range order; i.e. where the range is defined in ascending order, the selected entry with the lowest sequence-number is operated on first.
::= SET {
	child-entries	[0] 	BOOLEAN DEFAULT FALSE,
	range 			[1] 	Range OPTIONAL - -default is unbounded- -,
	link-choice	[5]	LinkChoice OPTIONAL - - default is no link-choice
	filter 			[2] 	Filter OPTIONAL -- default is all entries within the specified range--,
	limit 			[3] 	INTEGER (1.. ub-messages) OPTIONAL,
	override		[4]	OverrideRestrictions OPTIONAL -- default is that any fetch-restrictions 
						in force apply--}
The components child-entries, range, link-choice, filter, limit and override are defined as in X.413.
11.2.1.4	
The LinkChoice component of a selector indicates that, starting with a list of StartingPoints, certain links are to be followed and the objects found are to be returned.
::= SEQUENCE {
	starting-point	[0]	StartingPointList,
	link-arcs		[1]	LinkArcsList
	recursively	[2]	BOOLEAN DEFAULT TRUE
}
::= SEQUENCE OF AccObjectName
If recursively is TRUE, links are followed recursively from the objects found via the arcs from the initial object. Loops, where recursion gets back to an object already found, shall automatically be stopped, so that not more than one copy is found of each entry.

Figure %
Example of 
Figre % shows an example of recursive selection. A search for the moderators of activity A will find Moderator X and Moderator Y in the figure, if recursively is TRUE.
::= SEQUENCE OF { 
	SEQUENCE {
		link-type	[0] LinkType - - as defined in %.%.%.
		forward	[1] BOOLEAN - - whether links going from (forward) or to (not forward) are to be 
							followed
	}
}
FFS Note that this is not compatible with X.agc, since in X.agc, selection on links is done in another way (June 1993). (Priority = 1, June 1993)
11.2.1.5	
This attribute is defined identically to the corresponding attribute in X.413 | ISO/IEC 10021-5, except that MS attributes and entry-types are replaced by ACC attributes and entry-types. FFS. (Priority = 1, June 1993)
11.2.1.6	
This attribute is defined identically to the corresponding attribute in X.413 | ISO/IEC 10021-5, except that MS abstract-service-users are replaced by ACC abstract-service-users, and that ACC entries, not MS entries are transferred.
::= SEQUENCE {
	sequence-number	SequenceNumber,
	attributes				SET SIZE (1 .. ub-per-entry) OF Attribute OPTIONAL,
	value-count-exceeded	[0]	SET SIZE(1..ub-per-entry) OF AttributeValueCount OPTIONAL } 
::= SEQUENCE {
	type	[0]	ATTRIBUTE.&id ({AttributeTable}),
	total	[1]	INTEGER }
11.2.2	Format for forwarding items

::= CHOICE {
	entry-information 	[0] , - - as defined in X.413 but with X.acc attributes
	entry-content	[1] - - as defined in X.420, but with additional heading 
						extensions defined for ACC
}
ACC objects can be coded, when forwarded, in two formats:
(a)	The entry-information format. This format allows the sending of only some attributes, but can also be used to send all attributes of an item.
(b)	The entry-content format. This format is modelled after the IPM content format, and will make ACC contributions look very much like IPM message contents.
In the entry-content format, more than one item may be combined into one entry-content in several ways:
(i)	A contribution and its links may be combined into one heading. The links will then be represented as linking attributes in the heading, such as primary-recipient or replied-to-IPM.
(ii)	A digest entry-content can be produced. This contains a number of different entry-contents as body parts.
The table below shows when the entry-information and entry-content formats can be used:
	Entry-information	Entry-content	
Acc-submit	No	Yes	
Result of ACC-list or ACC-fetch	Yes	FFS (Priority = 1, June 1993)	
Forward-item	No	Yes	
11.2.3	Use of 
When group communication objects are transported in the format (defined in X.420), then the IPM heading fields are used in the following way:
IPM heading field	ACC representation	ACC name	Used on	
this-IPM	Attribute	acc-name/
contribution-identifier	Contributions	
originator	Attribute	acc-originator	All kinds	
authorizing-users	Attribute	acc-authorizing-users	All kinds	
primary-recipients	Link	primary-recipient	All kinds	
copy-recipients	Link	copy-recipient	All kinds	
blind-copy-recipients	Link	blind-copy-recipient	All kinds	
replied-to-IPM	Link	replied-to-IPM	Contributions	
obsoleted-IPMs	Link	obsoleted-IPM	Contributions	
related-IPMs	Link	related-IPM	Contributions	
subject	Attribute	subject	Contributions	
expiry-time	Attribute	expiry-time	Contributions, Activities	
reply-time	Attribute	reply-time	Contributions	
reply-recipients	Link	reply-recipients	Contributions	
importance	Attribute	importance	Contributions	
sensitivity	Attribute	sensitivity	Contributions	
auto-forwarded	Attribute	auto-forwarded	Contributions	
incomplete-copy	Attribute	incomplete-copy	Contributions	
languages	Attribute	contribution-languages	Contributions	
11.2.4	Additional 
When ACC objects are transported in the InformationObject format (defined in X.420) the following additional heading fields are defined.
For each attribute defined with the ATTRIBUTE macro in X.acc, there is a corresponding heading extension with type equal to the object identifier given in the ATTRIBUTE macro in X.acc and value restricted to the syntax defined in the ATTRIBUTE macro.
Here is an alphabetically sorted table of the additional heading extensions. By criticality means that if any of the attributes in the information object has criticality = yes, then the information object, when transported through the MTS, has the extended content type asynchronous-group-communication-1996 (also known as PACC). When all the attributes have criticality = no, then the information object, when transported through the MTS, has content type interpersonal-messaging-1988 (also known as P22).
Heading extension name	Syntax	Single/Multi-valued	Criticality	Object identifier	Specified in clause	
number-of-old-items-provided	INTEGER (0 .. MAX) 
DEFAULT 0	S	Yes	to be completed	8.13.5.3	
only-one-member	AccObjectDescriptor	S	Yes			
FFS The table above is VERY VERY incomplete (Priority = 2a, June 1993)						
11.2.5	Summary of abstract operations
The following abstract-operations are available at the Member Port:
	a)	ACC-Summarize;
b)	ACC-List;
c)	ACC-Fetch;
e)	ACC-Register;
g)	ACC-Submit.
Note – By submitting different kinds of notifications, many abstract user functions can be performed with the ACC-Submit operation.
Abstract-operations are performed asynchronously subject to the following conditions:
-	the ACC-Register abstract-operation shall not be performed until all outstanding abstract-operations have been completed;
-	the ACC-Register abstract-operation is performed in the order in which they are invoked and are allowed to complete before any other abstract-operation is performed. 
Because of this, and the fact that the ACC-List and ACC-Fetch abstract-operations may change the retrieval-status of a delivery entry, the results of the ACC-Summarize, ACC-List and ACC-Fetch abstract-operations may be non-deterministic.
11.2.6	
The ACC-Summarize abstract-operation returns summary counts of selected entries. In addition to these summaries, a count of the entries selected, and their lowest and highest sequence-numbers are also returned. Zero or more individual summaries may be requested. 
The ACC-Summarize abstract-operation will only be successful when access is permitted according to the security-context and the security-policy in force.
The attributes that may be used for summaries are not, in the ACC service, restricted to a subset of all attributes, as the X.413 summarize operation is.
The ACC-Summarize abstract-operation is further defined as in X.413 | ISO/IEC 10021-5, except that the operation is applied to the entry-types and attributes classes used in X.acc | ISO/IEC 10021-acc.
Example of use:
To perform the list-news abstract user function, i.e. to get a list of all activities with new items, indicating for each activity the number of new contributions and the number of new non-contribution objects, two summarize operations are necessary. One of these summarize operations could filter on objects where acc-retrieval-status is not processed and acc-class-type has the value {acc object-class contribution} or the object-id of subclass to that class. The other operation would be identical, but find objects where acc-class-type does not have the value {acc object-class contribution} or the object-id of a subclass to that class.
11.2.7	
The ACC-List abstract-operation is used to search for entries of interest, and to return selected or all information from those entries. 
The ACC-List abstract-operation will only be successful when access is permitted according to the security-context and the security-policy in force.
Note – The ACC-List operation in asynchronous group communication differs from the similar operation in operations on the Message store as defined in X.413, in that there is no restriction in asynchronous group communication on which attributes of the listed objects can be requested.
The ACC-List abstract-operation is further defined as in X.413 | ISO/IEC 10021-5, except that the operation is applied to the entry-types and attributes classes used in X.acc | ISO/IEC 10021-acc.
The ACC-List abstract-operation will cause the retrieval-status of the listed objects to be changed to listed or processed according to the same conventions as defined in X.420 clause 19.2.
11.2.8	
The ACC-Fetch abstract-operation is used to return selected information from a specific entry. Alternatively, it is used to return selected information from the first entry from among several entries of interest; in this case the sequence-numbers of the other selected entries are also returned. The ACC-Fetch abstract-operation will only be successful when access is permitted according to the security-context and the security-policy in force.
Information from an entry can be fetched several times, until the entry is deleted or purged.
The ACC-Fetch operation will only return information which is available in the ACC-SA to which the operation is given. The operation will thus not cause information to be searched for in other ACC-SAs.
The ACC-Fetch operation can, however, cause the ACC-SA to retrieve information from the directory, if the ACC-Fetch is performed on an object for which information can be expected to be found in the directory, such as an ACC-Fetch on an activity description.
The ACC-Fetch abstract-operation is further defined as in X.413 | ISO/IEC 10021-5, except that the operation is applied to the entry-types and attributes classes used in X.acc | ISO/IEC 10021-acc. Also, FetchArgument has in ACC the following defintion:
::= SET {
	item		CHOICE {
		search			[1]	Selector,
		precise		[2]	SequenceNumber
	},
	requested-attributes	[3]	EntryInformationSelection OPTIONAL,
	set-retrieval-status	[4]	RetrievalStatus OPTIONAL,
	...	-- For future extension additions -- }
The difference from X.413 is the set-retrieval-status attribute, which, if used, will cause the retrieval-status for this item in relation to this user to be set to the value given. If the set-retrieval-status attribute is omitted, the retrieval-status will be changed in the same way as for the ACC-List abstract operation.
11.2.9	
The is used to register or deregister various information with the ACC-SA:
a)	default requested attribute-types for ACC-List and ACC-Fetch;
b)	credentials;
c)	user-security-labels,
d)	UA registrations;
ACC-Register::= ABSTRACT-OPERATION
	ARGUMENT 	ACC-Register-Argument
	RESULT	ACC-Register-Result
	ERRORS {
		AttributeError,
		AutoActionRequestError,
		InvalidParametersError,
		SecurityError,
		ServiceError,
		OldCredentialsIncorrectlySpecified,
		NewCredentialsUnacceptable,
		...  -- 1994 extension additions -- ,
		ContentSpecificError,
		ACCRegisterError }
11.2.9.1	
 ::= SET {
	general-list-attribute-defaults	[2]	SET SIZE (1 .. ub-default-registrations) OF 
								ATTRIBUTE.&id ({AttributeTable})
								OPTIONAL,
	general-fetch-attribute-defaults	[3]	SET SIZE (1 .. ub-default-registrations) OF 
								ATTRIBUTE.&id ({AttributeTable})
								OPTIONAL,
	change-credentials		[4]	SEQUENCE {
								old-credentials	[0]	  Credentials,
								new-credentials	[1]  Credentials} OPTIONAL 
								-- same CHOICE as for old-credentials --,
	user-security-labels		[5]	SET SIZE (1 .. ub-labels-and-redirections) OF 
								SecurityLabel OPTIONAL,
	ua-registrations			[6]	SET SIZE(1..ub-ua-registrations) OF 
								UARegistration OPTIONAL,
	registration-status-request	[9]	RegistrationTypes OPTIONAL }
The parameters of the ACC-register-argument have the same definition as the corresponding parameters as defined in X.413 | ISO/IEC 10021-5, except that they apply to ACC users and ACC registrations.
FFS: Which are the register arguments for ACC? (Priority = 2, June 1993)
11.2.10	Alert abstract-operation
FFS Not copied from X.413! (Priority = 1, June 1993)
11.2.11	ACC-Modify abstract-operation
FFS Not copied from X.413! (Priority = 1, June 1993)
11.2.12	
The ACC-submit abstract-operation is used to submit one or several items to the ACC service. (Several items can be submitted by including them in a digest item.)
ACCSubmit ::= ABSTRACT-OPERATION
	ARGUMENT	ACCSubmissionArgument
	RESULT		ACCSubmissionResult
	ERRORS {
		SubmissionControlViolated,
		ElementOfServiceNotSubscribed,
		OriginatorInvalid,
		RecipientImproperlySpecified,
		InconsistentRequest,
		SecurityError,
		UnsupportedCriticalFunction,
		RemoteBindError,
		... -- 1994 extension additions -- ,
		ContentSpecificError,
		ServiceError }
11.2.12.1	Acc-submit-argument
::= SEQUENCE {
	COMPONENTS OF MessageSubmissionArgument -- This imported type is IMPLICITLY tagged -- ,
}
The parameters of Acc-submit-argument have the following meaning:
a)	Message-submission-argument: (M):  This contains the argument of the Message-submission abstract-operation as defined in 8.2.1.1.1 of CCITT Rec. X.411 | ISO/IEC 10021‑4. FFS?? (Priority = 2, June 1993) The submitted computer conferencing object is coded in the content of the message as defined in section 11.2.2: AccCodedObject.
	An extension to the MTS abstract-service is defined in this Recommendation | International Standard that may be present in the message-submission-argument (see 9.1 of CCITT Rec. X411 | ISO/IEC 10021‑4).
11.2.12.2	
Should the request succeed, the Acc-submit-result shall be returned. 
::=  SEQUENCE {
		created-entry			[2]	SequenceNumber OPTIONAL,
		forwarded-to-other-SA		[5]	BOOLEAN DEFAULT FALSE, - - indicates that the 
								- - requested-action will be performed by some other 
								- - ACC-SA, to which the request was forwarded
		response-item			[6]	ACCCodedObject OPTIONAL, }

The parameters of Acc-submit-result have the following meaning:
1)	Created-entry (C):  This indicates the sequence-number of the newly created entry.
2)	Response-item (C): This is used for those submitted items, which contain actions to be performed by the ACC-SA, and reports the result of these actions. The ACC-SA may also choose to send such response-items separately at a later time. The latter is the normal procedure when the ACC-SA forwards the submitted item to some other ACC-SA for action.
	Response-item is only included when the Acc-submit contained only one single submitted ACC object. When several ACC objects are submitted in one Acc-submit, then response-items will always be sent separately and not as part of the response-item to the Acc-submit operation.
11.2.12.3	
Should the request fail, one of the abstract-errors defined in clause %.%.% of this Recommendation | International Standard, or in 8.2.1.1.3 of CCITT Rec. X.411 | ISO/IEC 10021‑4 shall be reported.
11.3	Abstract-errors
This clause defines the following abstract-errors associated with using the abstract-operations at the Member Port:
a)	Attribute error;
c)	Delete error;
d)	Fetch restriction rror;
e)	Invalid parameters error;
f)	Range error;
g)	Security error;
h)	Sequence-number error;
i)	Service-error;
j)	Message-group error;
k)	Content-specific error;
m)	ACC-Register error
n)	ACC-Modify error;
11.3.1	Error precedence
The performer of an abstract-operation is not required to continue processing the contribution beyond the point at which an error has been detected. This allows an implementation to choose whether to continue the processing of errors.
NOTE - An implication of this rule is that the first error encountered may differ for repeated instances of the same abstract-operation, as there is not necessarily a specific logical order in which to process it.
11.3.2	Attribute-error
An Attribute-error reports an attribute related problem.
::= ABSTRACT-ERROR
	PARAMETER SET {
		problems		[0]	SET SIZE (1.. ub-per-entry) OF SET {
			problem			[0]	AttributeProblem,
			type			[1]	ATTRIBUTE.&id ({AttributeTable}),
			value			[2]	ATTRIBUTE.&Type ({AttributeTable} {@type}) 
								OPTIONAL} }
::= INTEGER {
	invalid-attribute-value		(0),
	unavailable-attribute-type		(1),
	inappropriate-matching 		(2),
	attribute-type-not-subscribed	(3),
	inappropriate-for-operation	(4)
	...  -- 1994 extension addition -- ,
	 inappropriate-modification	(5) } (0 .. ub-error-reasons)
The parameter has the following meaning:
a)	Problems (M): The particular problems encountered. Any number of individual problems may be indicated, each problem being accompanied by an indication of the attribute-type, and, if necessary to avoid ambiguity, the value which caused the problem:
1)	Invalid-attribute-value (C): A purported attribute-value specified as an argument of the abstract-operation does not conform to the data-type defined for the attribute-type concerned.
2)	Unavailable-attribute-type (C): A purported attribute-type used as an argument of the abstract-operation is not one of those which is supported by the ACC abstract-service-provider. If the ACC abstract-service-provider is able to carry out the operation anyway, it is not prohibited from doing so.
3)	Inappropriate-matching (C): The filter contains a filter-item in which an attribute is matched using a matching rule (equality, ordering, substrings, or other-match) that is not defined for that attribute-type or is not supported by the ACC Service.
4)	Attribute-type-not-subscribed (C): An attribute-type used as an argument of the abstract-operation is not one of those to which the ACC abstract-service-user has subscribed.
NOTE - A change of the subscription is not necessarily reflected in the attributes present in an entry created before the change. 
5)	Inappropriate-for-operation (C): An attribute-type used as an argument of the abstract-operation is unsuitable for its required use.
11.3.3	
A Fetch-restriction-error reports an attempt to violate a restriction associated with the ACC-Fetch abstract-operation.
FetchRestrictionError ::= ABSTRACT-ERROR
	PARAMETER  SET {
		problems	[0]	SET SIZE (1..ub-default-registrations) OF SET {
			problem		[3]	FetchRestrictionProblem,
			restriction		CHOICE {
				content-type		[0]	OBJECT IDENTIFIER,
				eit			[1]	ACC-EITs,
				content-length		[2]	ContentLength} }}
FetchRestrictionProblem ::= INTEGER {
	content-type-problem 	(1),
	eit-problem		(2),
	content-length-problem	(3),
	...-- For future extension additions -- } (0 .. ub-error-reasons)
The parameter has the following meaning:
a)	Problems (M): The particular problems encountered. Any number of individual problems may be indicated, each problem being accompanied by an indication of the offending content-type, encoded-information-type or content-length which caused the problem:
1)	Content-type-problem (C): The content-type of the message being fetched is disallowed by the fetch-restrictions currently in force.
2)	EIT-problem (C) : The encoded-information-types requested in the Fetch abstract-operation are disallowed by the fetch-restrictions currently in force.
3)	Content-length-problem (C): The content-length of the message being fetched is longer than that allowed by the fetch-restrictions currently in force.
11.3.4	Invalid-parameters-error
An Invalid-parameters-error reports a semantic problem in the set of parameters received. This error would be used, for example, to report that an optional parameter was present in the wrong context, or to report that a value for one of the parameters is inappropriate.
InvalidParametersError ::= ABSTRACT-ERROR
	PARAMETER  NULL
This error has no parameters.
11.3.5	
A Range-error reports a problem related to the range specified in a selector as an argument to an abstract-operation.
RangeError ::= ABSTRACT-ERROR
	PARAMETER  SET {
		problem	[0]	RangeProblem}
RangeProblem ::= INTEGER {
	reversed 	(0) } (0 .. ub-error-reasons)
The parameter has the following meaning:
a)	Problem (M): The particular problems encountered:
b)	Reversed (C): The upper bound indicated a sequence-number or creation-time before that indicated by the lower bound. 
11.3.6	
A Security-error reports that the requested abstract-operation cannot be provided because it would violate the security-policy in force. This error is defined in CCITT Rec. X.411 | ISO/IEC 10021-4.
11.3.7	
A Sequence-number-error reports a problem related to the sequence-number specified in an argument to an abstract-operation.
SequenceNumberError ::= ABSTRACT-ERROR
	PARAMETER SET {
		problems	[1]	SET SIZE (1..ub-messages) OF SET {
			problem		[0]	SequenceNumberProblem,
			sequence-number	[1] 	SequenceNumber} }
SequenceNumberProblem ::= INTEGER {
	no-such-entry		(0)} (0 .. ub-error-reasons)
The parameter has the following meaning:
a)	Problems (M): The particular problems encountered. Any number of individual problems may be indicated, each problem being accompanied by an indication of the sequence-numbers which caused the problem:
b)	No-such-entry: The sequence-number supplied does not match that of any entry.
11.3.8	
A Service-error reports an error related to the provision of the service.
ServiceError ::= ABSTRACT-ERROR
	PARAMETER  Service ErrorParameter
ServiceErrorParameter ::= SET {
	problem	[0]	ServiceProblem,
	...	-- 1994 extension addition -- ,
	supplementary-information	[1]	GeneralString (SIZE(1..ub-supplementary-info-length)) 
								OPTIONAL }
ServiceProblem ::=INTEGER {
	busy	(0),
	unavailable	(1),
	unwilling-to-perform	(2),
	...   -- For future extension additions -- } (0 .. ub-error-reasons)
The parameter has the following meaning:
a)	Problem (M): The particular problem encountered. If busy the ACC-SA, or some part of it, is presently too busy to perform the requested abstract-operation, but may be able to do so after a short while.  If unavailable the ACC, or some part of it, is presently unavailable.If unwilling-to-perform the ACC is not prepared to execute this request, because it would lead to excessive consumption of resources.
b)	Supplementary-information (O): This specifies further information which provides more details of the reported problem.
11.3.9	
A content-specific-error reports a problem concerning a content-specific parameter presented in the argument of an abstract-operation.  
ContentSpecificError ::= ABSTRACT-ERROR
	PARAMETER  CHOICE {
		content-defined-error	[0]	INSTANCE OF CONTENT-SPECIFIC,
		unknown-content-specific-parameter	[1]	NULL,
		...	-- For future extension additions -- }
The parameter has the following meaning:
a)	Content-defined-error (C):  An error occurred concerning some content-specific aspect of the performance of the abstract-operation.  The definition of an instance of a content-defined-error appears in the Recommendation | International Standard for the content-type concerned.
b)	Unknown-content-specific-parameter (C):  A content-specific parameter presented in the argument of the abstract-operation is not known to the ACC.
11.3.10	
An ACC-Register-error reports a problem in an attempt to register information with the ACC.
::= ABSTRACT-ERROR
	PARAMETER SET {
		problem	[0]	RegistrationProblem,
		registration-type	[1]	RegistrationTypes }
::= ENUMERATED {
	registration-not-supported	(0)
	registration-improperly-specified	(1),
	registration-limit-exceeded	(2),
	...	-- For future extension additions -- }
The parameter has the following meaning:
a)	Registration-problem (M):  The particular problem encountered.  Either the requested registration is not one of those supported by the ACC, or the request was improperly specified, or a pragmatic limit has been reached in the number of registrations that the ACC is able to record.
b)	Registration-type (M):  This indicated the type of registration requested by the ACC-user with which the problem is associated.
NOTE - Where a different abstract-error provides a more precise description of a registration problem, ACC-Register-error is not reported.
11.3.11	Activity-not-known-error
An activity-not-known-error is issued if the user ACC-SA cannot find the necessary information about an activity to perform an operation on that activity.
12.	
All of this chapter is new in version 13.
12.1	General operating procedures of an ACC-SA
12.1.1	How an ACC-SA can get new objects
An ACC-SA can get new objects from its registered ACC-UA-s, from other ACC-SA-s and as MHS messages (which can come from other ACC-SA-s, from MHS-users or from MTS distribution lists).
12.1.2	Redistribution of incoming object
When an ACC-SA receives an object from another ACC-SA, the information in the object is stored in the storage of the ACC-SA. If the object already is stored in the ACC-SA, only possible updates to the existing object are stored. Only the return-path of the first arriving copy of an object is stored. If the object is an announcement of an activity, this activity is looked up in the directory, and the directory information about the activity is, if necessary, added or updated.
The object is then distributed to those ACC-SA-s and MHS-UA-s who are registered to receive this object from this ACC-SA. (Such registrations can be made through update-distribution notifications.) It is also made available to those ACC-UA-s to whom it is addressed, or who are members of activities to which it is addressed. Such redistribution is limited by the distribution-area-list attribute of the incoming object and can be limited by access controls, size-limitations, depth-limitations etc. If distribution is stopped because of access controls and size-limitations, and unless the acc-submittor-report-request suppresses non-delivery-reports, such reports are sent to the originator when the distribution is stopped.
If an ACC-SA receives an object as an MHS message, with the dl-expansion-prohibited flag, then this message is not redistributed by the ACC-SA.
Contributions to pre-moderated activities will only be distributed to those members, who are not also moderators of the activity, when the ACC-SA receives an accepted-contribution from the contribution to the activity where withdrawn-by-originator has the value false.
12.1.3	Loop control
To avoid loops, where the same item is sent several times to the same recipient, an ACC-SA shall store incoming items for at least a few days. When an item arrives, the ACC-SA shall use the identifier of the arriving item to check if the ACC-SA already has a copy of that item. If so, the ACC-SA shall not distribute the item again to the activities to which it has already been distributed. Note, however, that an item may arrive again for distribution to new activities, and it must then be distributed to them again.
When an ACC-SA sends an item to a recipient, where the ACC-SA knows that the recipient already has the body of this item, the item can be sent without body, using the incomplete-copy heading field to indicate this.
12.1.3	
If an ACC-SA receives an object as an MHS message from an MHS distribution list, then the first distribution list in the DL-expansion-history is handled in the following way:
The ACC-SA will look for an activity with the same name as this distribution list. If such an activity is found, the object will be handled as a contribution to this activity. If no such activity is found, an activity with the same name as the distribution list is created, and the object will be handled as a contribution to this activity.
Note – This procedure may not be the best procedure for every kind distribution lists, but it is suitable for the most common usage of distribution lists.
12.2	
When an ACC-SA receives an object, it may also, perform some special action, triggered by the incoming object.
In particular, the following kinds of action may be triggered by incoming items. These actions are in general performed both when the ACC-SA receives the object from another ACC-SA and from one of its subscribing ACC-UA-s.
12.2.1	
When an ACC-SA receives a digest, it will perform any actions, triggered by the individual items in the digest, as if they were separate items. Redistribution of the digest may however be done in digest form, both to local ACC-UA-s, to other ACC-SA-s and to MHS recipients.
12.2.2	
An ACC-SA will often receive links together with the contributions they refer to, often as part of the same ACCObject in the entry-content format (IPM like format, see %.%.%). Links may however also be sent as separate link-objects to an ACC-SA.
Links from contributions to activities will tell the ACC-SA to which activities the contribution belongs, and the contribution (with its links) will then be redistributed according to the redistribution registered for objects belonging to this activity.
If an ACC-SA receives a link separately from the objects linked by it, then the ACC-SA will look up the linked objects in its storage, and for activities and participants, in the directory.
If an ACC-SA receives a link separately from the objects linked by it, and the objects can be found in the storage of the ACC-SA, then if the link instructs the ACC-SA to redistribute existing contributions to new activities, the ACC-SA will do this (subject to access control; this is a potentially security-sensitive operation!).
Links to MHS users can be used to instruct the ACC-SA to redistribute existing contributions as MHS messages to MHS users.
12.2.3	
When an ACC-SA receives an accepted-contribution notification, this instructs the ACC-SA to distribute the contribution, which the accepted-contribution refers to, to the members of the activity. The accepted-contribution is also forwarded, if so requested, to the submittor. The ACC-SA will also inhibit the submission link from the contribution to the activity.
12.2.4	
When an ACC-SA receives a rejected-submission notification, it will inhibit the submission link from the contribution to the activity. The rejected-submission is also forwarded, if so requested, to the submittor of the rejected submission.
12.2.5	
When an ACC-SA receives a submission to a pre-moderated activity for which it is the master ACC-SA, it will automatically create a submission-link from the submission to the activity.
The ACC-SA will, after creation of the submission-link, forward the submission with the submission-link to the moderators.
The submission-link will be burned by the ACC-SA, when it receives an accepted-contribution or rejected-submission from one of the moderators.
FFS: Alternative solution: Have a special “activity” for not-yet-accepted submissions. How should this activity then be named? (Priority = 1, June 1993)
12.2.6	
Attribute-adders and attribute-subtractors are redistributed in the same way as contributions.
12.2.7	
Object-inhibitors and s are redistributed in the same way as contributions. Further distribution of inhibited and burned objects is stopped, or the objects may be further distributed in the skeleton format (see %.%.%).
12.2.8	
An ACC-SA which is the master of an activity with master-copy-membership-handling will store the information from presence-reports on the link between the member and the activity. This information is used to produce memberlist-reports.
12.2.9	
A subscription-change will cause the ACC-SA which is the master of an activity with master-control-membership-handling to add or remove members, and report the changes to the requestor (with a confirmation) and to the participant whose membership is changed (with a membership-decision).
12.2.10	
A memberlist-finder will cause the ACC-SA which is the master of an activity with master-control-membership-handling to send a memberlist-report back to the originator of the memberlist-finder.
12.2.11	
An update-distribution notification will cause the receiving ACC-SA to update its stored instructions on from which activities new items are to be sent to other ACC-SA-s. It can also cause already stored items to be sent.
12.2.12	
A routing-report-request notification will cause the receiving ACC-SA to reply with a
12.2.13	Objects arriving in non-logical order and 
An ACC-SA cannot assume that incoming objects arrive in a logical order or in cronological order according to their original-creation-time. If an incoming object A causes some action to be taken by the ACC-SA on another object B, which the ACC-SA has not yet received, then a dummy object is created with the same ID as B. When an ACC-SA receives B, it will replace the dummy with the real B in its store. It will at the same time look up all incoming objects which contain a reference to B. When finding such an incoming object A, the ACC-SA will perform the actions which it normally would have performed at the arrival of A with B already present.
Note that if A was inhibited or burned before the arrival of B, no action will be caused by A. And if an inhibitor or burner on A arrived before A itself.
Dummy objects have the attribute dummy to identify them (see 8.5.12).
In particular:
•	At the receipt of a link, where one of the two linked objects is not available, the ACC-SA will create a dummy for the non-existing object. When the non-existing object arrives, the ACC-SA will perform the distribution which the link should have caused. Examples of links which may cause the ACC-SA to forward items are primary-recipient or accepted-contribution to cause distribution of an item to the members of an activity.
•	Rejected-submission: No submission link is created if the rejected-contribution arrives before the submission it refers to. The submission itself will, however, be distributed to the moderators.
•	Attribute-adder and attribute-subtractor: The resultant state will be the same as if these had arrived in cronological ordering of their original-creation-times.
•	Object-inhibitor and object-burner: If these arrive before the object they refer to, then when this object arrives, the action which it would normally have caused will never be performed.
Note – this means that it might be possible for a user to stop distribution of a contribution, if an inhibitor or burner are submitted with higher priority than the contribution to be removed.
12.3	
The ForwardItem abstract operation is used by an ACC-SA to put one or more items into a queue of items to be forwarded to one or more other ACC-SA-s. The actual forwarding will then be done using the inter-server-forwarding protocol.

	ARGUMENT SEQUENCE OF SEQUENCE {
		forwarded-object	[0] ACCObject, - - as defined in section %.%.%
		receiving-ACC-SA-s	[1] SEQUENCE OF ACCObjectName,
		priority			[2] Priority DEFAULT normal - - as defined in X.411
	}
	RESULTS SEQUENCE OF ForwardItemResult
	ERRORS (
		InvalidParametersError, SecurityError, ServiceError - - FFS to be completed  (Priority = 2a, June 1993))
::= SEQUENCE OF SEQUENCE {
	forwarded-object		[0] ACCObjectName,
	SEQUENCE OF SEQUENCE {
		receiving-ACC-SA-s	[0] ACCObjectName,
		will-be-forwarded	[1] BOOLEAN DEFAULT TRUE }
}
12.3.1	
12.3.2	Transmission-modes
 ::= SEQUENCE {
	transmission-protocol	[0] ENUMERATED {
							use-MTS (0), use-ROSE (1), use-DS (2), use-DFR (3) },
	transmission-initiator	[1] ENUMERATED {
							sending-ACC-SA (0), receiving-ACC-SA (1) },
	transmission-directness	[2] ENUMERATED {
							direct-transmission (0), indirect-transmission (1) },
	transmission-splitting	[3] ENUMERATED {
							each-object-separately (0), all-objects-packed-together (1) },
	maximum-accepted	[4] INTEGER OPTIONAL - - maximum number of bytes to be transmitted
}
FFS: Do we really need to support all these transmission modes? (June 1993) (Priority = 1, June 1993)
Items can be forwarded from one ACC-SA in one of several ways, depending on agreements between the ACC-SA-s:
With indirect-transmission is meant that the sending ACC-SA first sends a list of the ACCObjectNames of the objects to be transmitted. The receiving ACC-SA will then reply with a list of the ACCObjectNames of those objects it wants to get. The sending ACC-SA will then in a second step transmit the objects wanted.
12.3.3	Transmission in use-MTS mode
Stage 1: Transmission of a list of ACCObjectNames (only in indirect-transmission mode):
	SUBCLASS OF acc-notification
	MUST CONTAIN {
		offer-list
	}
	MAY CONTAIN {
		transmission-mode - - proposed mode for stage 2 and 3
	}
	::= {acc-class-offering}

	WITH ATTRIBUTE-SYNTAX
		OfferList
	MATCHES FOR ACC-EQUALITY SUBSETS
	::= {acc-attribute-type 1}
::= SEQUENCE OF SEQUENCE {
					offered-object		[0] ACCObjectName,
					is-it-a-dummy		[1] AccDummy
	}

	WITH ATTRIBUTE-SYNTAX
		MTS-transmission-mode
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
Stage 2: Request for a list of ACCObjectNames (in indirect-transmission mode):

	SUBCLASS OF acc-notification
	MUST CONTAIN {
		offer-list
	}
	MAY CONTAIN {
		transmission-mode - - proposed mode for stage 3
	}
	::= {acc-class-request}
The acc-request can be sent without any preceding acc-offering. The acc-request can contain names of objects not included in any acc-offering. The sending ACC-SA is not obliged to heed such requests for objects not offered.
Stage 3: The actual transmission of objects:
In the each-object-separately mode, each object is sent via the MTS as a separate message. Each message is coded in the entry-content format (see %.%.%) The content-type of this message is asynchronous-group-communication-1996 (also known as PACC) if it contains any critical attributes, otherwise it is interpersonal-messaging-1988 (also known as P22).
In the all-objects-packed-together mode, a compound MTS message is sent containing each object as one body part in the forwarded-IPM format. This mode is identified by the occurence of the compound-mode attribute in the outermost heading.

	WITH ATTRIBUTE-SYNTAX
		NULL
	MATCHES FOR EQUALITY
	::= {acc-attribute-type 1}
12.3.4	Transmission in use-
FFS (June 1993) (Priority = 1, June 1993)
12.3.5	Transmission in use-
FFS (June 1993) (Priority = 1, June 1993)
12.3.6	Transmission in use-
FFS (June 1993) (Priority = 1, June 1993)
12.4	
FFS: Below follows an excerpt from SC 18/WG4 N 2238. We should carefully investigate how this will fit with the rest of this document. (June 1992) (Priority = 1, June 1993)
The Control Abstract Operation exchanges negotiation and arbitration information among ACC-SAs. InterServerControlId is used to identify the control abstract operation. The Control Abstract Operation can exchange five control related information, negotiate-arguments, activity-control-arguments, read-arguments, list-transfer-arguments, and search-arguments. Negotiate-arguments are used to exchange mode-negotiation, especially, which server is responsible to distribute items. 
Activity-control-arguments are used to exchange activity-related information update. For example, newly created activity's information is distributed by this argument. The other three arguments are used to arbitrate distribution from receiver side NAD-SA's. Usually, the more descended nodes have more severe resource limitation, for example, smaller disk storage. In this case, the continuous distribution may do harm on smaller machine. To prevent some resource crash with overwhelming news incoming flow, NAD protocol can have options so that the receiver side can control incoming flow of news messages(NAD messages). 
Read-arguments are used to read item information from receiving side NAD-SA's. When read-arguments are used, the receiving side NAD-SA is safe because the NAD-SA has the choice to read the items. When the NAD-SA has resource limitation problem, it can postpone to read items. 
List-transfer-arguments and search-arguments are two methods for the receiving side NAD-SA to know whether there are items to read on the sender side NAD-SA.
	
	ARGUMENT ControlArgument
	RESULT	ControlResult
	ERROR {
		InvalideParametersError, SecurityError, ServiceError,
		TemporalError
	}
	::= SEQUENCE
	{
		interServerControlId [1] ControlId,
		argument [2] CHOICE {
			negotiate [1] NegotiateControlArguments,
			activity-control [2] ActivityControlArguments,
			-- Activity Control is different from 'Distribute', 
				OK?
			read [3] ReadArguments,
			list-transfer [4] ListTransferArguments,
			search [5] SearchArguments
		}
	}
There are several passive modes. In one mode, a passive receiver NAD-SA will use search and read for receiving items. In another mode, a passive receiver NAD-SA will wait for an active sender's list-transfer, then issues read for receiving items. In the other mode(and maybe most common case), a passive receiver NAD-SA does nothing on Control for receiving items, because items will transfer by an active sender NAD-SA using Distribute service.
Control-id is used to distinguish results and errors.
	::= SEQUENCE OF 
		SEQUENCE {
			control-id [1] ControlId,
			activity-message [2] NADActivityMessage
		}
ControlResults are one-to-one mappings from control arguments. Negotiate-results return the negotiated mode or resource limitation information. Activity-control-arguments return the success of activity related information update(including activity creation and activity deletion). Read-results return InterserverNADMessage. This result is equivalent of Deliver abstract operation. List-results return the success of transfer of available item information list at the sender NAD-SA side. Search results are used to transfer available item information list.
	::= CHOICE {
		negotiate-results [1] NegotiateControlResults,
		activity-control-arguments [2] SEQUENCE OF control-id,
		read-results [3] SEQUENCE OF InterserverNADMessage,
		list-results [4] SEQUENCE OF ListTransferArguments,
		search-results [5] SEQUENCE OF ListTransferArguments
	}
	::= SEQUENCE {-- for further studies
		current-mode	[0] TransferMode,
		acceptable-modes	[1] SEQUENCE OF TransferMode,
		resource-limitation [2] 
			SEQUENCE OF ResourceLimitationParameter OPTIONAL
	}
is used to transfer resource limitation information between NAD-SAs. The most common use of this parameter is 'running short of disk space'. Also, it will be used to 'next shutdown schedule'.
	ResourceLimitationParameter ::= CHOICE {
		description [1] NADGenralString,
		object-id [2] OBJECTIDENTIFER
	}
is used to transfer the negotiated TransferMode with resource limitation information. The argument is used to dynamically tune the item transfer flow between NAD-SAs.
	::= SEQUENCE {
		old-mode [0] TransferMode,
		new-mode [1] TransferMode,
		resource-limitation [2] ResourceLimitation OPTIONAL
	}
	::= SEQUENCE {
		parameter [1] ResourceLimitationParameter,
		content [2] 	CHOICE {
			string [1] NADGeneralString,
			number [2] INTEGER,
			time [3] UTCTime,	-- time related limitation,
			bit [4] BITSTRING -- set various control bits (for further studies)
		}
	}
is basically messages with accounting and token (= security related) information.
	::= SEQUENCE {
		messages [1] SEQUENCE OF NADM,
		accounting [2] SEQUENCE OF AccoutingInfo OPTIONAL
		tokens [3] SEQUENCE OF Token OPTIONAL
	}
	::= SEQUENCE  {
		list-information [1] ListInformation,
		accounting [2] SEQUENCE OF AccountingInfo,
		tokens [3] SEQUENCE OF Token
	}
	::=  SEQUENCE OF
		CHOICE {
		item [1] ItemReadArgument,
		activity [2] ActivityReadArguments
	}
	::= SEQUENCE OF
		CHOICE {
		item [1] ItemReadResult,
		activity [2] ActivityReadResult
	}
In ItemReadArgument, requested-attributes is optional because the whole item will be sent on ReadResult by default.
	::= 
		SEQUENCE 	{
		selector	[1] ItemSelector,
		requested-attributes [2] EntryInformationSelection OPTIONAL
	}
	::= 
		SEQUENCE {
		selector	[1] ActivitySelectorList,
		requested-attributes [2] EntryInformationSelection OPTIONAL
	}
	::= SEQUENCE {
		selector	[1] ActivitySelector,
		requested [2] SEQUENCE SIZE(1 .. ub-items) 
			OF EntryInformation OPTIONAL,
		activity-message [3] NADActivityMessage		-- ActivityInfo
	}
	::= SEQUENCE  {
		selector	[1] ItemSelector,
		requested [2] SEQUENCE SIZE(1 .. ub-items)
			 OF EntryInformation OPTIONAL,
		item [3] NADInterserverMessage	-- NADInterserverMessage
	}
	::= SEQUENCE 	{
		activity-range	[0] ObjectId,
		selector	[1] ItemSelector,
		requested-attributes [2] EntryInformationSelection OPTIONAL,
		filter	[3] Filter
	}
	::= SEQUENCE  OF ListInformation
Annex A: ASN.1 for the Computer Conferencing Abstract Service
The text of this annex is omitted in this printout of the working paper. The text is available in the version 9 of the X.acc | ISO/IEC 10021-acc working paper.
Annex B: Mapping of ACC operations on the Message Handling System (MHS)
For the Tokyo meeting, a first draft for Annex B is submitted as a separate document.
Annex C:	Mapping of ACC operations on the Directory System (DS)
Annex D:	Mapping of ACC operations on the Document Filing and Retrieval System (DFR)
Annex E:	Mapping between the ACC service and Internet mail/Netnews
This annex is for information only. The annex will be submitted as a proposal for an IETF standard. Final responsibility for the contents of that standard rests with IETF.
By Internet mail is meant a standard for message handling defined in RFC-821, RFC-822 and RFC 920. By netnews is meant a standard for computer conferencing defined in RFC-1036.
RFC 1327 is a standard for the mapping for interpersonal mail between X.400(1988) / ISO 10021 and RFC 822.
This annex is based on RFC1327, in that those data elements in ACC which are identical to corresponding data elements in X.411 or X.420, are mapped according to RFC 1327. This annex will only define the mapping for those data elements which ACC has but which do not exist in X.411 or X.420.
Internet mail	Netnews	X.acc	Comment	
To:, CC:, BCC:	Newsgroups:	primary-recipient (copy-recipient, blind-copy-recipient)	When the parameter is an activity or a distribution list.	
To:, CC:, BCC:	To: CC:, BCC 	primary-recipient (copy-recipient, blind-copy-recipient)	When the parameter is neither an activity nor a distribution list.	
In-reply-to:	In-reply-to: 	replied-to	Only used for personal mail replies.	
References:	References:	Related	Used for replies sent to activities.	
Obsoletes:	Obsoletes:	obsoletes		
Message-ID:	Message-ID:	this-IPM	The same value should never be reused again, even after several years.	
Received:	Path:	return-path	Names of servers, not of activities or distribution lists.	
Reply-To:	Reply-To:	reply-recipient	Where personal replies on this object should be sent.	
Followup-To:	Followup-To:	followup-to	Where group replies on this object should be sent.	
Expiry-Date:	Expires:	expiry-time		
	Control:	Objects whose class-type does not have as value {acc-class-contribution} or its subclasses		
Distribution:	Distribution:	distribution-area-list	Restrict distribution to a certain geographical or organisational area.	
Approved:	Approved:	accepted-contribution		
Organisation:	Organisation:	Element in the OR-name of the originator		
Keywords:	Keywords:	keywords		
Summary:	Summary:	summary		
Lines:	Lines:	lines		
Not available	Xref:	Not available	Only for local use	
Control: cancel <ID>	Control: cancel <ID>	object-inhibitor (object-burner)		
	Control: Ihave 
<ID list>	offering		
	Control: sendme 
<ID list>	request		
	Control: newgroup	activity-announcement		
	Control: rmgroup	object-inhibitor (object-burner)		
	Control: sendsys	routing-report-request		
	Control: version	FFS		
	batched news	digest		
Mapping of activity names and ACC-SA names? (Priority = 1a, June 1993)
Annex G:	Security Overview
To be completed
G.1	Introduction
G.2	Vulnerabilities
G.3	Vulnerability analysis
G.4	Security services
Annex H:	Index

Abstract of ACC concepts 4
Abstract Service Ports
figure 77
Abstract User Functions 77
Abstract-bind and Abstract-unbind Operations 103
Abstract-bind-argument 103
Abstract-bind-errors 104
Abstract-bind-result 104
Abstract-operations 104
Abstract-unbind-operation 104
ACC Link (subclass to ACC Item) 45
ACC Notifications (subclass to ACC Item) 60
ACC Object class 22
acc-acceptance-decision OBJECT-CLASS 56
acc-accepted-contribution OBJECT-CLASS 58
acc-activity OBJECT-CLASS 31
acc-activity-announcement OBJECT-CLASS 75
acc-aliases ATTRIBUTE 25
acc-announced activities ATTRIBUTE 76
acc-attribute-adder OBJECT-CLASS 63
acc-attribute-subtractor OBJECT-CLASS 64
acc-authorizing-users ATTRIBUTE 30
acc-class-type ATTRIBUTE 23
acc-contribution OBJECT-CLASS 41
ACC-Control-protocol 126
acc-distribution-area-list ATTRIBUTE 30
acc-dummy ATTRIBUTE 27
ACC-EQUALITY 17
ACC-Fetch abstract-operation 110
acc-followup-to OBJECT-CLASS 55
acc-free-form-name ATTRIBUTE 26
acc-item OBJECT-CLASS 40
acc-keywords ATTRIBUTE 30
acc-last-modification-time ATTRIBUTE 27
acc-last-modifier ATTRIBUTE 28
acc-lines ATTRIBUTE 42
acc-link OBJECT-CLASS 45
ACC-List abstract-operation 110
acc-locked-by ATTRIBUTE 28
acc-managers ATTRIBUTE 77
acc-master-copy-controlled ATTRIBUTE 29
acc-master-SA ATTRIBUTE 29
acc-member, acc-hidden-member, acc-owner, acc-administrator, acc-observer, acc-contributor 54
acc-memberlist-finder OBJECT-CLASS 69
acc-memberlist-report OBJECT-CLASS 70
acc-membership-decision OBJECT-CLASS 67
acc-moderator OBJECT-CLASS 54
acc-moderators ATTRIBUTE 76
acc-name ATTRIBUTE 23
acc-non-modifiable ATTRIBUTE 30
acc-notification OBJECT-CLASS 60
acc-object OBJECT-CLASS 22
acc-object-burner OBJECT-CLASS 65
acc-object-inhibitor OBJECT-CLASS 64
acc-offering OBJECT CLASS 124
acc-original-creation-time ATTRIBUTE 26
acc-participant OBJECT-CLASS 37
acc-presence-report OBJECT-CLASS 65
acc-previous-announcement ATTRIBUTE 76
acc-primary-recipient, acc-copy-recipient, acc-blind-copy-recipient OBJECT-CLASS 55
ACC-Register abstract-operation 111
ACC-Register-argument 112
ACC-Register-error 118
acc-rejected-submission OBJECT-CLASS 58
acc-replied-to, acc-obsoleted, acc-related OBJECT-CLASS 59
acc-reply-recipient OBJECT-CLASS 55
acc-request OBJECT CLASS 125
acc-retention-period ATTRIBUTE 28
acc-role OBJECT-CLASS 51
acc-routing-report OBJECT-CLASS 73
acc-routing-report-request OBJECT-CLASS 72
ACC-SA, abbreviation definition 2
ACC-SA-s
Communication between, figure 90
ACC-service-agent-retrieval 38
ACC-SP, abbreviation definition 2
acc-status ATTRIBUTE 28
acc-submission-link OBJECT-CLASS 56
Acc-submit Abstract-errors 114
Acc-submit abstract-operation 112
Acc-submit-result 113
acc-submittor-report-request ATTRIBUTE 46
acc-subscription-change OBJECT-CLASS 65
ACC-Summarize abstract-operation 109
acc-summary ATTRIBUTE 41
acc-super-activity, acc-open-for-member, acc-open-for-observer, acc-closed-for OBJECT-CLASS 59
ACC-UA, abbreviation definition 2
acc-update-distribution OBJECT-CLASS 72
acc-update-distribution-confirmation OBJECT-CLASS 74
ACCAP, abbreviation definition 2
ACCBindArgument 103
ACCBindResult 104
AccClassType 23
ACCCodedObject 107
ACCContributionSubmissionArgument 113
Accept 83
Accept and reject (realisation) 100
Acceptance-decision (subclass to ACC Link) 56
acceptance-notification-requested 47
Accepted-contribution (subclass to acceptance-decision) 58
Accepted-contribution, special actions 121
Access control on master-copy-controlled activities 88
Access control on non-master-copy-controlled activities 89
ACCObjectDescriptor 26
ACCObjectName 23
AccOriginatorReportRequest 46
ACCOStatus 28
ACCPreferredDeliveryMethod 38
ACCRegisterError 118
ACCS, abbreviation definition 2
ACCSP, abbreviation definition 2
ACCSubmissionResult 113
Active 28
Active objects 4
Activity 4
Activity names 24
activity object class 31
activity which is not master-copy-distributed 92
Activity-announcement (Subclass to both Activity and Item) 75
Activity-description 31
activity-description ATTRIBUTE 32
activity-name 23; 24
Activity-restriction 72
activity-restriction ATTRIBUTE 73
Activity-task 33
activity-task ATTRIBUTE 33
ActivityControlArguments 127
ActivityReadArgument 128
ActivityReadResult 129
Add-attribute 81
Add-attribute (realisation) 98
Add-link 82
Add-link (realisation) 98
Add-member 84
Add-member and remove-member (realisation) 101
Administrator 10; 53
Administrator port abstract user functions 102
Alias names 25
Allowed-content-types 34
allowed-content-types ATTRIBUTE 34
Announce-group-activity 84
Announce-group-activity (realisation) 101
Announced-activity 76
Announcement-request 73
announcement-request ATTRIBUTE 73
Anonymous-allowed 32
anonymous-allowed ATTRIBUTE 32
Anonymous-required 32
anonymous-required ATTRIBUTE 32
Apply-to 60
apply-to ATTRIBUTE 60
APPROXIMATE 17
Asynchronous Computer Conferencing Server Protocol (SA-SA-protocol, ACCSP) 119
asynchronous-computer-conferencing
= {acc-task-1} 33
Attribute-adder (subclass to ACC Notification) 63
Attribute-adder and attribute-subtractor, special actions 121
Attribute-subtractor (subclass to ACC Notification) 64
AttributeError 115
AttributeProblem 115
AttributeValueCount 107
Authorizing-users 30
Auto-forwarded 43
auto-forwarded ATTRIBUTE 43
Auto-submission-indication 44
auto-submission-indication ATTRIBUTE 44
Body 45
body ATTRIBUTE 45
Bulletin Board 4; 7
class hierarchy
figure 20; 21
Class-type 23
Co-location of IPM and Asynchronous Conferencing 95
Co-working with MHS 94
Coding of objects 107
Collapse 83
Collapse (realisation) 100
Common data-types used in abstract-operations 104
Communication between ACC-SA-s 89
figure 90
compound-mode ATTRIBUTE 125
Computer Conference 4; 7
Conference management port 77
Conference Service Manager 9
Confirmation 74
Confirmation-report ATTRIBUTE 75
Confirmation-requested 61
confirmation-requested ATTRIBUTE 61
Content-specific-error 118
Contribution 8
Contribution (subclass to ACC Item) 40
Contribution identifiers 24
contribution-digest ATTRIBUTE 44
contribution-identifier 23
Contributions 4
contributions which can be executed by their recipients 4
Contributor 11; 53
Control
= ABSTRACT-OPERATION 126
ControlArgument 126
ControlResults 127
Conversation 8
Create-group-activity 84
Create-group-activity (realisation) 101
Creation-time 26
DAP, abbreviation definition 2
Decision-taken 57
decision-taken ATTRIBUTE 57
DecisionTaken 57
Default-expiry-time 36
default-expiry-time ATTRIBUTE 36
Delete-group-activity 84
Delete-group-activity (realisation) 101
Delete-object 82
Delete-object (realisation) 99
Delivery notification 63
depth-limitation-on-contributions ATTRIBUTE 35
Describe-activity 79
Describe-activity (realisation) 96
Describe-member 83
Describe-member (realisation) 99
Describe-participant 82
Describe-participant (realisation) 99
DFR mode 126
DFRAP, abbreviation definition 3
DFRS, abbreviation definition 2
DFRSA, abbreviation definition 2
DFRUA, abbreviation definition 2
Digest 44
Digests, special actions 120
Distributed realisation of the computer conferencing service 86
Distribution from the responsible ACC-SA
figure 91
Distribution of links 50
Distribution of mocifications for a non-master-copy-controlled activity
figure 89
Distribution of new contributions 91
Distribution to an activity which is not master-copy-distributed
figure 92
Distribution when initially sent to a non-responsible ACC-SA
figure 91
Distribution-area-list 30
DL, abbreviation definition 2
Download news (realisation) 100
Download-news 83
Drawing conventions 3
Drawing conventions in object class diagrams
figure 3
Drawing conventions in object diagrams
figure 3
DS mode 125
DS, abbreviation definition 2
DSP, abbreviation definition 2
DUA, abbreviation definition 2
Dummy 27
dummy objects 122
Entity 9
Entry-information 106
Entry-information-selection 106
EntryInformation 107
EQUALITY 17
Execution of an Asynchronous Computer Conferencing Operation
figure 88
Expiry-time 35; 42
expiry-time ATTRIBUTE 35; 42
External participant 9
Fetch-restriction-error 115
FetchArgument 111
FFS, abbreviation definition 2
Filters 105
Find-activities 78
Find-activities (realisation) 95
Find-contributions 80
Find-contributions (realisation) 97
Find-members 82
Find-members (realisation) 99
Find-notifications 80
Find-notifications (realisation) 97
Find-submissions 83
Find-submissions (realisation) 100
Find-subscribed-activities 79
Find-subscribed-activities (realisation) 96
forms handling for specific group activities 4
Forward-item operation 123
ForwardItem ABSTRACT-OPERATION 123
ForwardItemResult 123
Free-form-name 26
Free-input-links 77
Frozen 28
GCAP, abbreviation definition 2
GCE, abbreviation definition 2
GCS, abbreviation definition 2
GCSA, abbreviation definition 2
GCUA, abbreviation definition 2
Group .i.activities 7
Group Activities and Contributions
figure 12
Group Activity 4
Group Activity Administrator 10
Group-activity object class 31
Grouping of owners
figure 13
heading extensions 108
help-desk 33
Hidden 28
Hidden-member 53
Hidden-members-allowed 33
hidden-members-allowed ATTRIBUTE 33
Identifiers, of contributions 24
Identifiers, of links 25
Immediate-confirmation 61
immediate-confirmation ATTRIBUTE 61
Importance 35; 42
importance ATTRIBUTE 35; 42
Incomplete 74
incomplete ATTRIBUTE 74
Incomplete-copy 44
incomplete-copy ATTRIBUTE 44
InformationObject 107
Inhibited 28
Integrated multi-user system with internal store
figure 93
Integrated multi-user system without internal store
figure 94
InterserverNADMessage 128
Introduction to ACC concepts 4
IPM heading fields 107
IPM, abbreviation definition 2
IPMS, abbreviation definition 2
IPMUA, abbreviation definition 2
Item (subclass to ACC Object) 40
ItemReadArgument 128
ItemReadResult 129
Joint editing of documents 4
joint-text-production 33
Keyword 30
Keywords 30; 81
Languages 35; 43
languages ATTRIBUTE 35; 44
Last-modification-time 27
Last-modifier 28
Last-present 39
last-present ATTRIBUTE 39
Lines 42
Link identifiers 25
Link object class 45
Link-from 46
link-from ATTRIBUTE 46
link-identifier 23
Link-to 46
link-to ATTRIBUTE 46
Link-type 47
link-type ATTRIBUTE 47
LinkArcsList 106
LinkChoice 105; 106
LinkName 25
Links 5
Links between contributions 6
Links between contributions and group activities
figure 5
Links between contributions forming conversations
figure 6
Links between group activities 7
figure 7
Links between group activities and contributions 5
Links between group activities and members 5
Links between participants and group activities
figure 6
Links from contributions, notifications and other items to group activities (subclasses to ACC Link) 54
Links from participants to group activities (subclasses to ACC Link) 50
Links. special actions 120
List of link types 47
List-news 79
List-news (realisation) 96
ListTransferArguments 128
Locked 28
Locked-by 27
Main concepts of computer conferencing
figure 5
main objects 4
Managers 76
Mark 81
Mark (realisation) 97
Master ACC-SA, definition 1
Master-copy-controlled 29
Master-copy-controlled, definition 2
Master-copy-distributed 36
master-copy-distributed activity 91
master-copy-distributed ATTRIBUTE 36
Master-copy-distributed, definition 2
Master-copy-membership-handling 36
master-copy-membership-handling ATTRIBUTE 36
Master-copy-membership-handling, definition 1
Master-SA 29
Matching rules 17
maximum-number-of-members ATTRIBUTE 69
Member 9; 10; 53
Member port 77
Member-list-available 33
member-list-available ATTRIBUTE 33
Member-name 67
Member-names-to-add 66
member-names-to-add ATTRIBUTE 66
Memberlist-error 71
memberlist-error ATTRIBUTE 71
Memberlist-finder 69
Memberlist-finder, special actions 122
Memberlist-report 70
MemberlistError 71
membername ATTRIBUTE 68
members 4
Membership-action 66
membership-action ATTRIBUTE 66
Membership-action-result 68
membership-action-result ATTRIBUTE 68
Membership-decision (acceptance, rejection, notification) 67
Membership-decision-reason 68
membership-decision-reason ATTRIBUTE 68
Membership-list 70
membership-list ATTRIBUTE 70
Membership-type 66
membership-type ATTRIBUTE 66
MembershipAction
= ENUMERATED { 66
MembershipDecisionReason 68
MembershipList 70
Memerbships
figure 12
MHS notifications 63
mhs-distribution-allowed ATTRIBUTE 37
mhs-submission-allowed ATTRIBUTE 36
Moderation-policies 32
moderation-policies ATTRIBUTE 32
ModerationPolicy 32
Moderator 10
Moderator (subclass to role) 54
Moderator port 77
Moderators 76
Modify-group-activity 84
Modify-group-activity (realisation) 102
Modify-profile 83
Modify-profile (realisation) 100
MRA, abbreviation definition 3
MTS Envelope fields 45
MTS, abbreviation definition 2
Name (of all kinds of computer conferencing objects) 23
Names of activities 24
Names, of contributions 24
Names, of Links 25
Names, of participants 24
Navigation of an Asynchronous Computer Conferencing Operation
figure 87
NegotiateControlArguments 127
NegotiateControlResults 127
News control 14; 15
figure 15
non-delivery notification 63
Non-members-can-submit 34
non-members-can-submit ATTRIBUTE 34
Non-modifiable 29
Not-all-members-listed 71
not-all-members-listed ATTRIBUTE 71
NotAllMembersListed 71
Notification 8
Number-of-old-items-provided 68
number-of-old-items-provided ATTRIBUTE 69
Number-of-old-items-wanted 67
number-of-old-items-wanted ATTRIBUTE 67
NumberOfOldItemsWanted 67
object (common attributes for all ACC objects) 22
Object coding format 107
object-burner 121
Object-Burner (subclass to ACC Notification) 64
Object-descriptor 25
Object-inhibitor (subclass to ACC Notification) 64
Object-inhibitor and object-burner, special actions 121
objects in asynchronous computer conferencing 4
Observer 11; 53
offer-list ATTRIBUTE 124
OfferList 125
onfirmation-report 75
Only-one-member 69
only-one-member ATTRIBUTE 69
Operations on .i.non-master-copy-controlled activities 89
Operations on master-copy-controlled activities 87
ORDERING 17
Organizations 35
organizations ATTRIBUTE 35
Original-creation-time 26
Originator-name 25
Overview and Model 3
Overview of the Asynchronous Computer Conferencing Data Model 4
Owner 11
Owner, Administrator, Member, Observer, Contributor 53
Participant 9
Participant names 24
Participant object class 37
Participant-description 38
participant-description ATTRIBUTE 38
participant-name 23
Participant-preferred-delivery-method 38
participant-preferred-delivery-method ATTRIBUTE 38
Participant-statistics 39
participant-statistics ATTRIBUTE 39
Participants 4
ParticipantStatistics 39
Personal-reply 81
Personal-reply (realisation) 98
Ports
figure 77
Ports and Functions 77
Presence-report (subclass to ACC Notification) 65
Presence-report, special actions 122
PRESENT 17
Previous-announcement 76
Priority 44
Prospective member 10
prospective members 7
Purpose of ACC service 4
Range 105
Range-error 116
Read-item 80
Read-item (realisation) 97
ReadArgument 128
ReadResult 128
Realisation of the Abstract User Functions 86; 95
Receipt notification 63
Reciept of objects from MHS distribution list 120
Recursive LinkChoice
figure 106
Register-participant 84
Register-participant and unregister-participant (realisation) 102
RegistrationProblem 118
Reject 83
Reject-subscription-request 84
Reject-subscription-request (realisation) 101
Rejected-submission (subclass to acceptance-decision) 58
Rejected-submission, special actions 121
rejection-notification-suppressed 47
Rejection-reason 58
rejection-reason ATTRIBUTE 58
Remove-attribute 82
Remove-attribute (realisation) 98
Remove-item 82
Remove-link (realisation) 99
Remove-member 84
Reply-time 42
reply-time ATTRIBUTE 42
Reported-member 65
reported-member ATTRIBUTE 65
ResourceLimitation 128
ResourceLimitationParameter 127
Retention-period 28
retrieval-status 14; 15; 29
Return-path 27
return-path ATTRIBUTE 27
role 9
Role-attribute-restrictor 70
role-attribute-restrictor ATTRIBUTE 70
Role-given 68
role-given ATTRIBUTE 68
role-holders linked to an activity
figure 51
role-holders, holding the same role, can be grouped into a role activity
figure 51
Role-last-present 52
role-last-present ATTRIBUTE 53
Role-preferred-delivery-method 52
role-preferred-delivery-method ATTRIBUTE 52
Role-restrictor 69
role-restrictor ATTRIBUTE 70
Role-statistics 53
role-statistics ATTRIBUTE 53
Role-wants-all 52
role-wants-all ATTRIBUTE 52
Roles 50
RoleStatistics 53
ROSE mode 125
Routing (realisation) 102
Routing-report 73
routing-report ATTRIBUTE 74
Routing-report-request 72
Routing-report-request, special actions 122
Scope and Limits of Scope 3
SearchArgument 129
SearchResult 129
Security-error 117
Sees-rejected-submissions 54
sees-rejected-submissions ATTRIBUTE 54
Selector 105
Sensitivity 42
Sequence-number-error 117
Server-restriction 73
server-restriction ATTRIBUTE 73
Service-error 117
Size-limitation-on-contributions 34
size-limitation-on-contributions ATTRIBUTE 34
Size-limitation-on-replies 34
size-limitation-on-replies ATTRIBUTE 34
Special actions triggered by certain objects 120
Special rules for specific group activities 4
StartingPointList 106
Status 28
Subclass, definition 2
Subject 41
subject ATTRIBUTE 41
Submission 8
Submission procedure
figure 14
Submission-link (subclass to ACC Link) 56
Submission-reference 57
submission-reference ATTRIBUTE 57
Submissions to pre-moderated activities, special actions 121
Submit-item 81
Submit-item (realisation) 97
Submittor-report-request 46
Subscription-change (subclass to Acc-notification) 65
Subscription-change, special actions 122
Subscription-request 79
Subscription-request (realisation) 96
SUBSTRINGS 17
Summary 41
Suspend-group-activity 84
Suspend-group-activity (realisation) 101
Synchronous group communication 4
Tickets 49
TimeLapse 29
Transmission of objects between ACC-SA-s 124
Transmission-mode 124
transmission-mode ATTRIBUTE 125
Triggered-by 61
triggered-by ATTRIBUTE 61
UA with co-located single user store
figure 93
Unregister-participant 84
Update-distribution 71
Update-distribution, special actions 122
Update-distribution-action 72
update-distribution-actions ATTRIBUTE 72
UpdateDistributionActions 72
User ACC-SA, definition 2
Voting 4; 33
Withdraw-submission 81
Withdraw-submission (realisation) 98
Withdrawn-by-originator 57
withdrawn-by-originator ATTRIBUTE 58
Withdrawn-by-submittor 57
withdrawn-by-submittor ATTRIBUTE 57