Asynchronous Computer Conferencing Working Document ISO/IEC JTC 1/SC 18/WG 4 Version 13, June 1993, Printed 10/04/93:19:14  CCITT Study Group VII/Q.14 i Group Communication Editor: Jacob Palme, Stockholm University Skeppargatan 73, S-11530 Stockholm, Sweden Phone: +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). Other aspects of Message Handling Systems and Services are defined in other Recommendations. The layout of Recommendations defining the Message Handling System and Services is shown in Recommendation F.400/X.400, Table 1. The public services built on MHS, as well as access to and from the MHS for public services are defined in the F.400 series of Recommendations. The technical aspects of MHS are defined in the X.400 series of Recommendations. The overall system architecture of MHS is defined in Recommendation X.402. Other aspects of Directory Systems are defined in other Recommendations. The layout of Recommendations defining the Directory System and Services is shown in Recommendation F.500/X.500, Table 1. The public services built on DS, as well as access to and from the DS for public services are defined in the F.500 series of Recommendations. The technical aspects of DS are defined in the X.500 series of Recommendations. The overall system architecture of DS is defined in Recommendation X.501. The general model for the Group Communication System and Services is defined in documents F.agc/X.agc. That document also describes a mapping of the Asynchronous Computer Conferencing Service on the general Group Communication model. 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 .i.Accept, definition; The act when a moderator in a pre-moderated activity accepts contributions to it. .i.Activity, definition; See Group Communication Activity. .i.Contribute, definition; The act of making a contribution available to the members of an activity. Compare with the term submit. .i.Contribution, definition; An item containing a body of text contributed by a user to the other members of an activity. .i.Group Communication Activity, definition; A set of contributions exchanged between a set of members on a common topic or task. .i.Item, definition; An item is an information object. Examples of items are contributions, notifications and activity presentations. .i.Master ACC-SA, definition; The ACC-SA which controls an activity which is either master-copy-controlled, master-copy- distributed or has master-copy-membership- handling. .i.Master-copy- controlled, definition; 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. .i.Master-copy- distributed, definition; 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. .i.Master-copy- membership-handling, definition; 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. .i.Moderation, definition; 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). .i.Moderator, definition; Specially authorized members of an activity which can control which contributions are allowed in the activity. .i.Obsolete, definition; The act of contributing a contribution which obsoletes a previous contribution. .i.Post-moderation, definition; 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. .i.Pre-moderation, definition; Control of the contributions in an activity, such that only contributions approved by the moderators are distributed to the members of the activity. .i.Reject, definition; The act when a moderator in a pre-moderated activity rejects contributions to it. .i.Subclass, definition; 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. .i.Submission, definition; A contribution which has been submitted, but which has not yet been accepted by the moderators. .i.Submit, definition; 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. .i.Subscribe, definition; The act of indicating that a participant wants to participate in a particular activity. .i.Subscription, definition; The storage of information that a participant subscribes to a particular activity. .i.Text, definition; 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. .i.User ACC-SA, definition; The ACC-SA to which serves a certain user. .i.Active period, definition; The time between the date of adding a contribution to a group activity and its removal from the activity. .i.Asynchronous, definition; 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. .i.Atomic Object, definition; An information object with its initial set of attributes at is first submission. .i.Attribute Carrier, definition; An atomic object used to add, change or delete attributes for an information object. .i.Collaborative Group Communication, definition; 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. .i.Contribution, definition; A message submitted within Asynchronous Computer Conferencing. .i.Conversation, definition; A set of messages related directly or indirectly by links such as inReplyTo, RelatedTo, Obsoletes etc. .i.Derived Object, definition; A derivation rule, and the set of information objects implicitly defined by this derivation rule. .i.Development- history, definition; A set of messages related directly or indirectly to an original message by Obsoletes attributes. .i.Distribution and Subscription, definition; A service for providing the distribution of information objects to a set of subscribers. Also known as News Distribution. .i.Distribution list, definition; An agent in the MTS, which will redistribute incoming messages to a list of subscribers. .i.Distribution list management, definition; The actions of creating and deleting distribution lists, adding and removing subscribers from them. Also the process of managing a set of nested lists. .i.Group activity, definition; 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. .i.Group Communication, definition; Tools to enable several people to cooperate via open communication systems. See also Social Group Communication and Collaborative Group Communication. .i.Information Object, definition; A piece of information handled in group communication, such as messages or documents. .i.Inter-personal Communication, definition; The transfer of a communication object from and by a designated orginator to one or more designated receivers. .i.Keyword, definition; Word added to an information object to be used in searches. .i.Administrator, definition; (of a group activity) One or more OR-names designating users or roles with special controlling rights on roles within an activity. .i.Modified Object, definition; An atomic object, which has been changed by the addition, removal or change of one or more attributes. .i.News Control, definition; A service enabling a DFRSUA to download only those information objects which are new to it. .i.News Distribution, definition; See Distribution and Subscription. .i.Restricted Domain, definition; Limiting the distribution of a contribution to recipients within a certain geographical or organizational area. .i.Retention period, definition; The time after the removal of a contribution from a group activity, during which it can be recreated using the undo facility. .i.Role, definition; 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. .i.Social Group Communication, definition; 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. .i.Synchronous, definition; Cooperation which takes place in real time, i.e. the users cooperating are at one and the same time exchanging information. 5. Abbreviations .i.DL, abbreviation definition; Distribution List .i.FFS, abbreviation definition; For Further Study .i.GCE, abbreviation definition; Group Communication Environment .i.GCS, abbreviation definition; Group Communication Service .i.GCSA, abbreviation definition; Group Communication Service Agent .i.GCUA, abbreviation definition; Group Communication User Agent .i.GCAP, abbreviation definition; Group Communication Access Protocol, the protocol between a GCUA and a GCSA .i.ACC-SP, abbreviation definition; Computer Conferencing Service Protocol, the protocol between two ACC-SA-s .i.ACCS, abbreviation definition; Computer Conferencing Service .i.ACC-SA, abbreviation definition; Computer Conferencing Service Agent .i.ACC-UA, abbreviation definition; Computer Conferencing User Agent .i.ACCAP, abbreviation definition; Computer Conferencing Access Protocol, the protocol between an ACC-UA and an ACC-SA .i.ACCSP, abbreviation definition; Computer Conferencing Service Protocol, the protocol between two ACC-SA-s .i.IPM, abbreviation definition; Inter-Personal Messaging .i.IPMS, abbreviation definition; Inter-Personal Messaging Service .i.IPMUA, abbreviation definition; Inter-Personal User Agent .i.MTS, abbreviation definition; Message Transfer Service .i.DS, abbreviation definition; Directory System .i.DUA, abbreviation definition; Directory System User Agent .i.DAP, abbreviation definition; Directory Access Protocol, the protocol between a DUA and a DSA .i.DSP, abbreviation definition; Directory System Protocol, the protocol between two DSA-s .i.DFRS, abbreviation definition; Document Filing and Retrieval Service .i.DFRUA, abbreviation definition; Document Filing and Retrieval User Agent .i.DFRSA, abbreviation definition; Document Filing and Retrieval Service Agent .i.DFRAP, abbreviation definition; DFR Access Protocol, The protocol between a DFRUA and a DFRSA .i.MRA, abbreviation definition; 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 .i.Drawing conventions; These drawing conventions are used in most of the drawings in this recommendation. Figure % .i.Drawing conventions in object diagrams: figure Figure % .i.Drawing conventions in object class diagrams: figure 7. Asynchronous Computer Conferencing .i.Overview and Model 7.1 .i.Scope and Limits of Scope 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 Ò.i.Bulletin Board;Ó Ò.i.News Group;Ó and Ò.i.Computer Conference;Ó are commonly used terms to describe what in this standards is called Ò.i.Group Activity;Ó or sometimes only Ò.i.Activity;Ó. The services described in this recommendation do not include certain advanced computer conferencing services. For example, the following services are not included: ¥ .i.Voting;. ¥ .i.Joint editing of documents;. ¥ .i.Synchronous (same time) group communication;. ¥ .i.Special rules for specific group activities;. ¥ Special .i.forms handling for specific group activities;. ¥ Ò.i.Active objects;Ó, i.e. .i.contributions which can be executed by their recipients; ¥ Ò.i.Work flow handling;Ó, i.e. .i.task specifications; and controlled .i.circulation of documents;, 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 .i.Class 1 Asynchronous Computer Conferencing Data Model .i.Introduction to ACC concepts;.i.Abstract of ACC concepts;.i.Purpose of ACC service The three .i.main objects;.i.objects in asynchronous computer conferencing ;are .participants, group activities and contributions. .i.Participants ;represent people and other entities that are active users of computer conferencing. .i.Contributions ;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 .i.topic;. A group activity allows a number of participants, called .i.members ;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 % .i.Main concepts of 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 .i.Contribution; 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 .i.Submission; Figure % .i.Handling of submissions to pre-moderated activities: 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. .i.Forwarding: of contributions from activity to activity; A similar format is used when a contribution, originally submitted to one activity, is forwarded to other activities. 7.2.4.3 .i.Notification; 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 .i.Entity; 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 .i.Participant; An entity who has been registered to use the conferencing service is called a participant. 7.2.5.3 .i.Conference Service Manager; 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 .i.External participant 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 .i.Links; 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 % .i.Format of a link object Examples of uses of links are given in the following section. 7.2.2.1 .i.Links from contributions to activities; 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 % .i.Links from contributions to group activities: figure 7.2.2.1 .i.Equivalence of links and IP-forwarding 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 .i.Links from members to its group activities; 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 % .i.Links from members to group activities: 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 .i.Links between contributions; 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 % .i.Links between contributions forming conversations: figure 7.2.2.4 .i.Links between group activities; Links between activities can be used to create a hierarchy of group activities, as is shown in figure %. Figure % .i.Links between group activities: figure 7.2.3 Grouping contributions and participants 7.2.3.1 .i.Group .i.activities; 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 .i.computer conference ;, .i.newsgroup ;or .i.bulletin board ;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 .i.prospective members;. ¥ 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 .i.Conversation; 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. by In-reply-to or Obsoletes links. These links form a directed acyclic graph. Note that Related-to links do not form conversations as defined here. 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 .i.Member ;(Group Activity Member) A link from a participant to a particular group activity is called a .i.role;. 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 .i.Prospective member; 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 .i.Member;) A regular member is a member of a group activity who reads and writes contributions. Access controls may limit the capabilities of regular members in various ways (e.g. Ôread-onlyÕ, 'contribute-onlyÕ). 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 .i.Moderator ;(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 .i.Administrator ;(.i.Group Activity Administrator;) 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 .i.Owner ;(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 .i.Observer ;(Group Activity Observer) An observer is a member who can only read, not write contributions in an acitivty. 7.2.6.9 .i.Contributor ;(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 .i.Group Activities and Contributions: figure 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 .i.Memberships: figure 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 .i.Grouping of owners: figure 7.3.4 .i.News control; 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. .i.Retrieval-status ;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 .i.Matching rules; When performing search operations, attributes can be compared using the three matching rules defined in X.413 chapter 12: .i.EQUALITY;, .i.SUBSTRINGS ;, .i.ORDERING;., .i.PRESENT ;and .i.APPROXIMATE;. In addition to this, an additional matching rule is introduced, with the name .i.ACC-EQUALITY;. 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 Singl /mult -valued 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 .i.class hierarchy: figure acc-top acc-object item parti- cipant contr -bution link notificat on activ ty ?? superacti ity, open-for- member, open-for- observer, closed-for replied- to, obsolet d, related role ?? member, hidden- member, owner, administr tor, observer, contribut r, moderator primary- recipient, copy- recipient, blind- copy- recipient, reply- recipient, followup- to, submissio -link, acceptanc -decision, accepted- contribut on, rejected- contribut on attribute- adder, attribute- subtracto , object- inhibitor, object- burner, presence- report, subscript on-change, membershi -decision, memberlis -finder, memberlis -report, update- distribut on, update- distribut on- confirmat on, routing- report- request, routing- report activ ty- annou -cement Table % Full computer Conferencing .i.class hierarchy: figure 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 .i.object (common attributes for all ACC objects) 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 .i.ACC Object class; .i.acc-object OBJECT-CLASS; 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 .i.Class-type; This attribute contains the object identifier for the OBJECT-CLASS of this object. .i.acc-class-type ATTRIBUTE; WITH ATTRIBUTE-SYNTAX AccClassType MATCHES FOR EQUALITY ::= {acc-attribute-type 1} .i.AccClassType ;::= OBJECTIDENTFIER 8.5.4 .i.Name (of all kinds of computer conferencing objects); 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. .i.acc-name ATTRIBUTE; WITH ATTRIBUTE-SYNTAX ACCObjectName MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} .i.ACCObjectName ;::= CHOICE { .i.activity-name; [0] ORName, - - as defined in X.411 - - but with mandatory directory-name .i.participant-name; [1] ORName, - - as defined in X.411 .i.contribution-identifier; [2] IPMIdentifier, - - as defined in X.420 .i.link-identifier; [3] LinkName - - as defined below } 8.5.4.1 .i.Activity names;.i.Names of activities; The name of an activity is an OR-name in the same format as in the name of an MHS users. However, within the .i.activity-name;, 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 .i.Participant names;.i.Names, of participants; 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 .i.Contribution identifiers;.i.Names, of contributions;.i.Identifiers, of contributions; 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 .i.Link identifiers;.i.Names, of Links;.i.Identifiers, of links; .i.LinkName ;::= 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 .i.Alias names; ACC activities can have alias names. Such alias names have the format of directory alias names. .i.acc-aliases ATTRIBUTE; WITH ATTRIBUTE SYNTAX SET OF Name - - as defined in X.501 MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 12} 8.5.6 .i.Originator-name; 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 .i.Object-descriptor; 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. .i.ACCObjectDescriptor ;::= 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 .i.Free-form-name; This data type contains an object name, which is not globally unique, but which is user-friendly and suitable for user interfaces. .i.acc-free-form-name ATTRIBUTE; WITH ATTRIBUTE SYNTAX FreeFormName - - as defined in X.420 MATCHES FOR EQUALITY SUBSTRINGS ::= {acc-attribute-type 13} 8.5.9 .i.Original-creation-time; This attribute identifies the time when a computer conferencing object was created and entered into the ACC service. .i.acc-original-creation-time ATTRIBUTE; 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 .i.Creation-time; 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 This attribute identifies one or more participants who have full control of this object. acc-owner ATTRIBUTE WITH ATTRIBUTE SYNTAX SET OF ACCOobjectDescriptor DEFAULT acc-originator MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 15} 8.5.12 .i.Return-path 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. .i.return-path ATTRIBUTE; 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 .i.Dummy; 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. .i.acc-dummy ATTRIBUTE; 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 .i.Last-modification-time; This attribute shows the last time when this object was modified. .i.acc-last-modification-time ATTRIBUTE; WITH ATTRIBUTE SYNTAX UTCTime - - as defined in X.208 MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.5.15 .i.Locked-by; This attribute contains the name of a participant who has locked this object temporarily in order to modify it. .i.acc-locked-by ATTRIBUTE; 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 .i.Last-modifier; This attribute contains the name of the participant who made the last modification of this object. .i.acc-last-modifier ATTRIBUTE; WITH ATTRIBUTE SYNTAX ACCOobjectDescriptor DEFAULT acc-originator MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 15} 8.5.17 .i.Status; This attribute can have the following values: .i.Act ve;: Normal status. .i.Hid en;: No one can view this object. .i.Fro en;: Can be viewed but not modified. .i.Loc ed;: Temporarily locked while being modified. .i.Inh bited;: Deleted, but might still be viewed and the deletion can be undone (period from logical deletion to physical deletion) .i.acc-status ATTRIBUTE; WITH ATTRIBUTE SYNTAX ACCOStatus MATCHES FOR EQUALITY ::= {acc-attribute-type 15} .i.ACCOStatus ;::= ENUMERATED { active (0), hidden(1), frozen (2), locked(3), inhibited(4) } 8.5.18 .i.Retention-period; This attribute gives a minimum time when this object should stay in the inhibited state before allowing it to be physically purged. .i.acc-retention-period ATTRIBUTE; WITH ATTRIBUTE SYNTAX TimeLapse MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 15} .i.TimeLapse ;::= SEQUENCE { minutes INTEGER (0 .. 59), hours INTEGER (0 .. 23), days INTEGER (0 .. MAX), } 8.5.19 .i.Master-copy-controlled; This attribute indicates whether all modifications of this object must be done via an ACC-SA holding a master copy of the object. .i.acc-master-copy-controlled ATTRIBUTE; WITH ATTRIBUTE SYNTAX BOOLEAN DEFAULT FALSE MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.5.20 .i.Retrieval-status; 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 .i.Master-SA; 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. .i.acc-master-SA ATTRIBUTE; WITH ATTRIBUTE SYNTAX ACCOobjectDescriptor MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 15} 8.5.22 .i.Non-modifiable; 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. .i.acc-non-modifiable ATTRIBUTE; WITH ATTRIBUTE SYNTAX BOOLEAN DEFAULT FALSE MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.5.23 .i.Distribution-area-list; 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. .i.acc-distribution-area-list ATTRIBUTE; 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) FFS: Perhaps Distribution-area-list should be an attribute of links, not of objects, and should then control the distribution of objects linked by this link. This would allow the redistribution of objects, originally submitted to a limited distribution-area, to a larger such area (June 1993). 8.5.24 .i.Keywords; This attribute gives keywords for use in searches for this object. .i.acc-keywords ATTRIBUTE; WITH ATTRIBUTE SYNTAX SET OF Keyword MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 15} .i.Keyword ;::= CaseIgnoreStringSyntax - - as defined in X.520 8.5.25 .i.Authorizing-users; This attribute is used as defined in X.420. .i.acc-authorizing-users ATTRIBUTE; 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 .i.Group-activity object class;.i.activity object class .i.acc-activity OBJECT-CLASS; 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 .i.Activity-description; 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. .i.activity-description ATTRIBUTE; WITH ATTRIBUTE SYNTAX Case-ignore-string - - as defined in X.500 MATCHES FOR EQUALITY SUBSTRINGS ::= {acc-attribute-type 15} 8.6.3 .i.Moderation-policies; This attribute gives information about the moderation policies applicable in this activity. .i.moderation-policies ATTRIBUTE; WITH ATTRIBUTE SYNTAX ModerationPolicy MATCHES FOR EQUALITY ::= {acc-attribute-type 15} .i.ModerationPolicy ;::= 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 .i.Anonymous-allowed; 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) .i.anonymous-allowed ATTRIBUTE; WITH ATTRIBUTE SYNTAX BOOLEAN DEFAULT FALSE MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.6.5 .i.Anonymous-required; When this attribute is TRUE, all contributions to this activity must be anonymous or pseudonymous. .i.anonymous-required ATTRIBUTE; WITH ATTRIBUTE SYNTAX BOOLEAN DEFAULT FALSE MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.6.6 .i.Hidden-members-allowed; When this attribute is TRUE, the activity can have members, whose existence are not divulged to other members. .i.hidden-members-allowed ATTRIBUTE; WITH ATTRIBUTE SYNTAX BOOLEAN DEFAULT FALSE MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.6.7 .i.Member-list-available; 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. .i.member-list-available ATTRIBUTE; WITH ATTRIBUTE SYNTAX BOOLEAN DEFAULT TRUE MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.6.8 .i.Activity-task; This attribute can be used to describe different kinds of activities. .i.activity-task ATTRIBUTE; 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: .i.asynchronous-computer-conferencing ::= {acc-task-1}; .i.voting; ::= {acc-task-2} .i.joint-text-production; ::= {acc-task-3} .i.help-desk;::= {acc-task-4} 8.6.9 .i.Non-members-can-submit; When this attribute is true, submissions from non-members are accepted for this activity. .i.non-members-can-submit ATTRIBUTE; WITH ATTRIBUTE SYNTAX BOOLEAN DEFAULT TRUE MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.6.10 .i.Allowed-content-types; This attribute indicates which content types are allowed for this activity. .i.allowed-content-types ATTRIBUTE; WITH ATTRIBUTE SYNTAX SET OF ContentType - - ContentType as defined in X.411 MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.6.11 .i.Size-limitation-on-contributions; This attribute specifies a maximum size in number of characters of non-replying contributions to this activity. .i.size-limitation-on-contributions ATTRIBUTE; WITH ATTRIBUTE SYNTAX INTEGER DEFAULT MAX MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.6.12 .i.Size-limitation-on-replies; This attribute specifies a maximum size in number of characters of contributions to this activity which are related to other contributions. .i.size-limitation-on-replies ATTRIBUTE; 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. .i.depth-limitation-on-contributions ATTRIBUTE; 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. .i.allowed-body-part-types ATTRIBUTE; 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 .i.Expiry-time; This attribute indicates a future data when this activity will be frozen or deleted. .i.expiry-time ATTRIBUTE; WITH ATTRIBUTE SYNTAX UTCTime MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.6.15 .i.Languages; This attribute indicates one or more languages used within an activity. .i.languages ATTRIBUTE; WITH ATTRIBUTE SYNTAX SET OF Language - - As defined in X.420 Annex A MATCHES FOR EQUALITY SUBSTRINGS ::= {acc-attribute-type 15} 8.6.16 .i.Importance; This attribute gives a priority classification of the activity according to the views of the owner of the activity. .i.importance ATTRIBUTE; WITH ATTRIBUTE SYNTAX Importancefield - - As defined in X.420 MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.6.17 .i.Organizations; This attribute gives the names of one or more organization responsible for running this activity. .i.organizations ATTRIBUTE; 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 .i.Default-expiry-time; This attribute contains a default expiry time to be applied to contributions in this activity which do not have a different explicit expiry time. .i.default-expiry-time ATTRIBUTE; WITH ATTRIBUTE SYNTAX TimeLapse MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.6.20 .i.Master-copy-distributed; When this attribute is true, all contributions must first be entered into the master copy of the activity. .i.master-copy-distributed ATTRIBUTE; WITH ATTRIBUTE SYNTAX BOOLEAN DEFAULT FALSE MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.6.21 .i.Master-copy-membership-handling; 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. .i.master-copy-membership-handling ATTRIBUTE; 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. .i.mhs-submission-allowed ATTRIBUTE; 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. .i.mhs-distribution-allowed ATTRIBUTE; 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 .i.Participant object class; .i.acc-participant OBJECT-CLASS; 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 .i.Participant-description; A personal description, written by this user, of information which s/he wants to provide to others, like interests, tasks etc. .i.participant-description ATTRIBUTE; WITH ATTRIBUTE SYNTAX CaseIgnoreString MATCHES FOR EQUALITY SUBSTRINGS ::= {acc-attribute-type 15} 8.8.3 .i.Participant-preferred-delivery-method; When this attribute is true, submissions from non-members are accepted for this activity. .i.participant-preferred-delivery-method ATTRIBUTE; WITH ATTRIBUTE SYNTAX ACCPreferredDeliveryMethod MATCHES FOR EQUALITY ::= {acc-attribute-type 15} .i.ACCPreferredDeliveryMethod ;::= 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 .i.ACC-service-agent-retrieval ;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 .i.Last-present; 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. .i.last-present ATTRIBUTE; WITH ATTRIBUTE SYNTAX UTCTime MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.8.5 .i.Participant-statistics; When this attribute is true, submissions from non-members are accepted for this activity. .i.participant-statistics ATTRIBUTE; WITH ATTRIBUTE SYNTAX ParticipantStatistics MATCHES FOR EQUALITY ::= {acc-attribute-type 15} .i.ParticipantStatistics ;::= 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 .i.Item (subclass to ACC Object) 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. .i.acc-item OBJECT-CLASS; 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 .i.Contribution (subclass to ACC Item); 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. .i.acc-contribution OBJECT-CLASS; 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 .i.Subject Semantics as defined in X.420. .i.subject ATTRIBUTE; WITH ATTRIBUTE SYNTAX SubjectField - - as defined in X.420 MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.10.2 .i.Summary The summary can be used to give a short abstract of a long contribution. .i.acc-summary ATTRIBUTE; WITH ATTRIBUTE SYNTAX CaseIgnoreString - - as defined in X.500 MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.10.3 .i.Lines 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. .i.acc-lines ATTRIBUTE; WITH ATTRIBUTE SYNTAX INTEGER MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.10.4 .i.Expiry-time Semantics as defined in X.420. .i.expiry-time ATTRIBUTE; WITH ATTRIBUTE SYNTAX ExpiryTimeField - - as defined in X.420 MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.10.5 .i.Reply-time; This field gives a desired reply time both for personal replies to the author and to group replies to the whole group. .i.reply-time ATTRIBUTE; WITH ATTRIBUTE SYNTAX ReplyTimeField - - as defined in X.420 MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.10.6 .i.Importance; Semantics as defined in X.420. .i.importance ATTRIBUTE; WITH ATTRIBUTE SYNTAX ImportanceField - - as defined in X.420 MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.10.7 .i.Sensitivity; 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 .i.Auto-forwarded; Semantics defined in X.420. .i.auto-forwarded ATTRIBUTE; 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 .i.Languages; Semantics defined in X.420. .i.languages ATTRIBUTE; WITH ATTRIBUTE SYNTAX Languages - - as defind in X.420 Annex A MATCHES FOR EQUALITY SUBSTRINGS ::= {acc-attribute-type 15} 8.10.12 .i.Incomplete-copy; This attribute indicates by its present that one or more body parts may be missing from this copy of this contribution. .i.incomplete-copy ATTRIBUTE; WITH ATTRIBUTE SYNTAX NULL - - as defined in X.420 Annex A MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.10.13 .i.Auto-submission-indication; Semantics as defined in X.420. .i.auto-submission-indication ATTRIBUTE; WITH ATTRIBUTE SYNTAX BOOLEAN DEFAULT FALSE - - as defined in X.420 Annex A MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.10.14 .i.Priority; 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 .i.Digest; 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. .i.contribution-digest ATTRIBUTE; 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 .i.Body; .i.body ATTRIBUTE; WITH ATTRIBUTE SYNTAX Body - - as defined in X.420 MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.10.17 .i.MTS Envelope fields; 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 .i.ACC Link (subclass to ACC Item) 8.12.1 .i.Link object class; .i.acc-link OBJECT-CLASS; ; 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 .i.Link-from This attribute gives the name of the object from which this link goes. .i.link-from ATTRIBUTE; 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 .i.Link-to This attribute gives the name of the object to which this link goes. .i.link-to ATTRIBUTE; 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 .i.Submittor-report-request; This attribute indicates what kind of reports the submittor wants from the distribution using this link. .i.acc-submittor-report-request ATTRIBUTE; WITH ATTRIBUTE SYNTAX AccSubmittorReportRequest MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 15} .i.AccOriginatorReportRequest ;::= 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 .i.acceptance-notification-requested ;and the .i.rejection- notification-suppressed ;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 .i.Link-type; This attribute gives the type of the link. .i.link-type ATTRIBUTE; WITH ATTRIBUTE SYNTAX LinkType - - as defined earlier MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.12.6 .i.List of link types;Link types, list of 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 .i.Tickets; 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 .i.Distribution of links;Links, distribution of 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 .i.Links from participants to group activities (subclasses to ACC Link); 8.13.1 .i.Roles; A role is a link from a participant to a group actvity (see figure %) . Figure % A number of .i.role-holders linked to an activity: figure 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 .i.role-holders, holding the same role, can be grouped into a role activity: figure;. 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. .i.acc-role OBJECT-CLASS; 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 .i.Role-preferred-delivery-method; 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. .i.role-preferred-delivery-method ATTRIBUTE; WITH ATTRIBUTE SYNTAX ACCPreferredDeliveryMethod MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.13.1.4 .i.Role-wants-all; 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. .i.role-wants-all ATTRIBUTE; WITH ATTRIBUTE SYNTAX RoleWantsAll BOOLEAN DEFAULT TRUE MATCHES FOR EQUALITY ::= {acc-attribute-type 15} 8.13.1.5 .i.Role-last-present; 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. .i.role-last-present ATTRIBUTE; WITH ATTRIBUTE SYNTAX UTCTime MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.13.1.6 .i.Role-statistics; 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. .i.role-statistics ATTRIBUTE; WITH ATTRIBUTE SYNTAX RoleStatistics MATCHES FOR EQUALITY ::= {acc-attribute-type 15} .i.RoleStatistics ;::= 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 .i.Owner, Administrator, Member, Observer, Contributor;, Hidden-member (subclasses to role) The Owner, .i.Administrator;, .i.Member;. .i.Hidden-member;, .i.Observer ;and .i.Contributor ;are subclasses of Roles with no added attributes. Their structure is thus: .i.acc-member, acc-hidden-member, acc-owner, acc-administrator, acc- observer, acc-contributor 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 .i.Moderator (subclass to role) .i.acc-moderator OBJECT-CLASS; SUBCLASS OF acc-role MUST CONTAIN { } MAY CONTAIN { sees-rejected-submissions} ::= { accclass-moderator} 8.13.4 .i.Sees-rejected-submissions; .i.sees-rejected-submissions ATTRIBUTE; 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 .i.Links from contributions, notifications and other items to group activities (subclasses to ACC Link); 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. .i.acc-primary-recipient, acc-copy-recipient, acc-blind-copy-recipient OBJECT-CLASS; 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. .i.acc-reply-recipient OBJECT-CLASS; 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. .i.acc-followup-to OBJECT-CLASS; SUBCLASS OF acc-link MUST CONTAIN { } MAY CONTAIN { } } ::= { acc-class-followupTo} 8.14.4 .i.Submission-link (subclass to ACC Link); 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. .i.acc-submission-link OBJECT-CLASS; SUBCLASS OF acc-link MUST CONTAIN { } MAY CONTAIN { } } ::= { acc-class-submissionLink} 8.14.5 .i.Acceptance-decision (subclass to ACC Link); 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. .i.acc-acceptance-decision OBJECT-CLASS; 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 .i.Submission-reference; This attribute conveys a reference to the submission being accepted or rejected. .i.submission-reference ATTRIBUTE; WITH ATTRIBUTE SYNTAX ACCOobjectDescriptor MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 15} 8.14.5.2 .i.Decision-taken; This attribute indicates whether the submission is accepted or rejected. .i.decision-taken ATTRIBUTE; WITH ATTRIBUTE SYNTAX DecisionTaken MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 15} .i.DecisionTaken ;::= ENUMERATED { accepted (1), auto-accepted (2), rejected (3), auto-rejected (4), withdrawn-by-submittor(5), withdrawn-by-originator(6) } 8.14.5.3 .i.Withdrawn-by-submittor; Indicates that the participant who submitted this contribution has withdrawn it. .i.withdrawn-by-submittor ATTRIBUTE; WITH ATTRIBUTE SYNTAX BOLEAN DEFAULT FALSE MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 15} 8.14.5.4 .i.Withdrawn-by-originator; Indicates that the participant who originated this contribution has withdrawn it. .i.withdrawn-by-originator ATTRIBUTE; WITH ATTRIBUTE SYNTAX BOLEAN DEFAULT FALSE MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 15} 8.14.6 .i.Accepted-contribution (subclass to acceptance-decision); 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. .i.acc-accepted-contribution OBJECT-CLASS; SUBCLASS OF acc-acceptance-decision MUST CONTAIN { MAY CONTAIN { ::= {acc-class-acceptedContribution} 8.14.7 .i.Rejected-submission (subclass to acceptance-decision); 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. .i.acc-rejected-submission OBJECT-CLASS; SUBCLASS OF acc-acceptance-decision MUST CONTAIN { MAY CONTAIN { rejection-reason ::= {acc-objectClass 1} 8.14.7.1 .i.Rejection-reason; This attribute contains arguments for rejecting this submission, which can be sent from the rejector to the submittor. .i.rejection-reason ATTRIBUTE; 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. .i.acc-replied-to, acc-obsoleted, acc-related OBJECT-CLASS; 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. .i.acc-super-activity, acc-open-for-member, acc-open-for-observer, acc-closed-for OBJECT-CLASS; SUBCLASS OF acc-link MUST CONTAIN { } MAY CONTAIN { } } ::= { acc-class-superActivity} ::= { accclass-openForMember} ::= { accclass-openForObserver} ::= { accclass-closedFor} 8.17 .i.ACC Notifications (subclass to ACC Item); 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 .i.acc-notification OBJECT-CLASS; 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. .i.Apply-to; This attribute indicates that this notification applies to another ACC object, whose name is given in the attribute. .i.apply-to ATTRIBUTE; WITH ATTRIBUTE-SYNTAX AccObjectDescriptor MATCHES FOR EQUALITY ::= {acc-attribute-type 1} 8.17.3. .i.Confirmation-requested; 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. .i.confirmation-requested ATTRIBUTE; 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. .i.Immediate-confirmation; 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. .i.immediate-confirmation ATTRIBUTE; WITH ATTRIBUTE-SYNTAX BOOLEAN DEFAULT FALSE MATCHES FOR EQUALITY ::= {acc-attribute-type 1} 8.17.5. .i.Triggered-by; 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. .i.triggered-by ATTRIBUTE; 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. .i.MHS notifications;Notifications, from MHS The following MHS notifications are available in computer conferencing too as follows: MHS notification Availability and use in computer conferencing .i.Delivery notification;, .i.non-delivery notification;, 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. .i.Receipt notification;, 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. .i.Attribute-adder (subclass to ACC Notification); 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. .i.acc-attribute-adder OBJECT-CLASS; 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. .i.Attribute-subtractor (subclass to ACC Notification); 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. .i.acc-attribute-subtractor OBJECT-CLASS; 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. .i.Object-inhibitor (subclass to ACC Notification); 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. .i.acc-object-inhibitor OBJECT-CLASS; 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. .i.Object-Burner (subclass to ACC Notification); 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. .i.acc-object-burner OBJECT-CLASS; 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. .i.Presence-report (subclass to ACC Notification); 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. .i.acc-presence-report OBJECT-CLASS; 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.11.1 .i.Reported-member; This attribute gives the names of the member whose presence is reported. .i.reported-member ATTRIBUTE; WITH ATTRIBUTE-SYNTAX AccObjectDescriptor MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} 8.17.12. .i.Subscription-change (subclass to Acc-notification); 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. .i.acc-subscription-change OBJECT-CLASS; 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 .i.Member-names-to-add; This attribute gives the names of the participants who are to be added or removed. .i.member-names-to-add ATTRIBUTE; WITH ATTRIBUTE-SYNTAX SEQUENCE OF ACCoObjectDescriptor DEFAULT acc-originator MATCHES FOR EQUALITY ::= {acc-attribute-type 1} 8.17.12.2 .i.Membership-action; This attribute indicates how membership is to be changed. .i.membership-action ATTRIBUTE; WITH ATTRIBUTE-SYNTAX MembershipAction MATCHES FOR EQUALITY ::= {acc-attribute-type 1} .i.MembershipAction ::= ENUMERATED {; added-as-member(0), rejected-as-member(1), excluded-from-membership(2), no-action-taken(3), other(4) } 8.17.12.3 .i.Membership-type; 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. .i.membership-type ATTRIBUTE; WITH ATTRIBUTE SYNTAX ACCObjectDescriptor MATCHES FOR ACCO-EQUALITY ::= {acc-attribute-type 15} 8.17.12.4 .i.Number-of-old-items-wanted; 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. .i.number-of-old-items-wanted ATTRIBUTE; WITH ATTRIBUTE SYNTAX NumberOfOldItemsWanted MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} .i.NumberOfOldItemsWanted ;::= 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. .i.Membership-decision (acceptance, rejection, notification) ; (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. .i.acc-membership-decision OBJECT-CLASS; 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 .i.Member-name; This attribute gives the name of the participant affected. .i.membername ATTRIBUTE; WITH ATTRIBUTE-SYNTAX AccObjectDescriptor MATCHES FOR EQUALITY ::= {acc-attribute-type 1} 8.17.13.2 .i.Membership-action-result; This attribute indicates how membership is to be or has been changed. .i.membership-action-result ATTRIBUTE; WITH ATTRIBUTE-SYNTAX MembershipAction - - as defined earlier MATCHES FOR EQUALITY ::= {acc-attribute-type 1} 8.17.13.3 .i.Membership-decision-reason; .i.membership-decision-reason ATTRIBUTE; WITH ATTRIBUTE-SYNTAX MembershipDecisionReason MATCHES FOR EQUALITY ::= {acc-attribute-type 1} .i.MembershipDecisionReason ;::= BITSTRING { automatic (0), activity-unknown (1), access-control-rejection (2), technical-error (3) } 8.17.13.4 .i.Role-given; 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. .i.role-given ATTRIBUTE; 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 .i.Number-of-old-items-provided; This attribute indicates how many old items will be sent to the new member. .i.number-of-old-items-provided ATTRIBUTE; WITH ATTRIBUTE SYNTAX INTEGER (0 .. MAX) DEFAULT 0 MATCHES FOR EQUALITY ORDERING ::= {acc-attribute-type 15} 8.12.10 Submission-withdrawal (subclass to ACC-notification) A acc-submit-withdrawal is sent to a pre-moderated activity to withdraw a not yet accepted contribution. It is normally only allowed to be made by the submitter or the originator, and indicates that the submission is withdrawn. Accepted submissions cannot be withdrawn, but not-yet-accepted as well as rejected submissions can be withdrawn. acc-submit-withdrawal OBJECT-CLASS SUBCLASS OF acc-notification MUST CONTAIN { withdrawn-submission } MAY CONTAIN { } ::= {acc-class-submitWithdrawal} 8.13.6.1 Withdrawn-submission This attribute contains a reference to the recipient link which is withdrawn. withdrawn-submission ATTRIBUTE WITH ATTRIBUTE-SYNTAX AccObjectDescriptor MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} 8.17.14. .i.Memberlist-finder; 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. .i.acc-memberlist-finder OBJECT-CLASS; 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 .i.Only-one-member; This attribute indicates that not all members are requested, only the membership status for one particular member is wanted. .i.only-one-member ATTRIBUTE; 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. .i.maximum-number-of-members ATTRIBUTE; WITH ATTRIBUTE-SYNTAX INTEGER MATCHES FOR EQUALITY ::= {acc-attribute-type 1} 8.17.14.3 .i.Role-restrictor; This attribute indicates that only membership of certain roles are wanted .i.role-restrictor ATTRIBUTE; WITH ATTRIBUTE-SYNTAX SET OF AccClassType MATCHES FOR EQUALITY ::= {acc-attribute-type 1} 8.17.14.4 .i.Role-attribute-restrictor; 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. .i.role-attribute-restrictor ATTRIBUTE; WITH ATTRIBUTE-SYNTAX RoleAttributeRestrictor MATCHES FOR EQUALITY ::= {acc-attribute-type 1} RoleAttributeRestrictor ::= BIT STRING { last-present-wanted (0) statistics-wanted (1) } 8.17.15. .i.Memberlist-report; A memberlist-report notification is returned as a response to a memberlist-finder. .i.acc-memberlist-report OBJECT-CLASS; 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 .i.Membership-list; This attribute includes the list of the members of the activity. .i.membership-list ATTRIBUTE; WITH ATTRIBUTE-SYNTAX MembershipList MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} .i.MembershipList ;::= SEQUENCE OF EntryInformation 8.17.15.2 .i.Not-all-members-listed; This attribute indicates that less than all members of the activity is returned. .i.not-all-members-listed ATTRIBUTE; WITH ATTRIBUTE-SYNTAX NotAllMembersListed MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} .i.NotAllMembersListed ;::= 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. .i.Memberlist-error; This attribute indicates that no membership list can be found. .i.memberlist-error ATTRIBUTE; WITH ATTRIBUTE-SYNTAX MemberlistError MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} .i.MemberlistError ;::= ENUMERATED { no-error (0), activity-not-known (1) } 8.17.17. .i.Update-distribution; 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. .i.acc-update-distribution OBJECT-CLASS; 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 .i.Update-distribution-action; .i.update-distribution-actions ATTRIBUTE; WITH ATTRIBUTE-SYNTAX UpdateDistributionActions MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} .i.UpdateDistributionActions;::= 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. .i.Routing-report-request; 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. .i.acc-routing-report-request OBJECT-CLASS; SUBCLASS OF acc-notification MUST CONTAIN { } MAY CONTAIN { activity-restriction, server-restriction, announcement-request } ::= {acc-class-routingReportRequest} 8.17.18.1 .i.Activity-restriction The activity-restriction, if present, reduces the routing report to only a report for the listed activities. .i.activity-restriction ATTRIBUTE; WITH ATTRIBUTE-SYNTAX SEQUENCE OF AccObjectDescriptor MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} 8.17.18.2 .i.Server-restriction The server-restriction, if present, reduces the routing report to only a report on distribution to the listed servers. .i.server-restriction ATTRIBUTE; WITH ATTRIBUTE-SYNTAX SEQUENCE OF AccObjectDescriptor MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} 8.17.18.3 .i.Announcement-request The announcement-request, if present, indicates that announcements are wanted for all activities. .i.announcement-request ATTRIBUTE; WITH ATTRIBUTE-SYNTAX BOOLEAN DEFAULT FALSE MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} 8.17.19. .i.Routing-report 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. .i.acc-routing-report OBJECT-CLASS; SUBCLASS OF acc-notification MUST CONTAIN { routing-report } MAY CONTAIN { incomplete } ::= {acc-class-routingReport} 8.17.19.1 .i.Routing-report; 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. .i.routing-report ATTRIBUTE; 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 .i.Incomplete; 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. .i.incomplete ATTRIBUTE; WITH ATTRIBUTE-SYNTAX BOOLEAN DEFAULT FALSE MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} 8.17.20. .i.Confirmation; 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. .i.acc-update-distribution-confirmation OBJECT-CLASS; 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.i.onfirmation-report; .i.Confirmation-report ATTRIBUTE; 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. .i.Activity-announcement (Subclass to both Activity and Item) 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. .i.acc-activity-announcement OBJECT-CLASS; 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 .i.Announced-activity; .i.acc-announced activities ATTRIBUTE; WITH ATTRIBUTE-SYNTAX AccObjectDescriptor MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} 8.17.21.2 .i.Previous-announcement; If this actvity has been announced before, then the acc-previous- announcement attribute refers to the latest previous announcement of the same activity. .i.acc-previous-announcement ATTRIBUTE; WITH ATTRIBUTE-SYNTAX AccObjectDescriptor MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} 8.17.21.3 .i.Moderators; 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. .i.acc-moderators ATTRIBUTE; WITH ATTRIBUTE-SYNTAX SEQUENCE OF AccObjectDescriptor MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} 8.17.21.4 .i.Managers; 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. .i.acc-managers ATTRIBUTE; WITH ATTRIBUTE-SYNTAX SEQUENCE OF AccObjectDescriptor MATCHES FOR ACC-EQUALITY ::= {acc-attribute-type 1} 8.17.22. .i.Free-input-links; 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 .i.Abstract User Functions; 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 .i.Ports and Functions; Asynchronous conferencing functions are grouped into three ports as shown in figure 1: Figure % Asynchronous Computer Conferencing .i.Abstract Service Ports: figure;.i.Ports: figure The .i.Member port ;provides the functionality associated with members. The .i.Moderator port ;provides additional functionality for managing an activity. The .i.Conference management port ;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 .i.Find-activities;(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) .i.Find-subscribed-activities;(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. .i.Describe-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. .i.Subscription-request;(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.) .i.List-news;(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. .i.Find-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. .i.Find-notifications;(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. .i.Read-item;(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) .i.Mark;(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) .i.Submit-item;(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) .i.Withdraw-submission;(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. .i.Personal-reply;(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. .i.Add-attribute;(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: ¥ .i.Keywords; Note Ð The contribution is not itself modified. Instead, an add- attribute is appended to it. .i.Remove-attribute;(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. .i.Add-link ;(ACCName participant, Link-object) -> Status Used to submit a link. .i.Remove-item;(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. .i.Delete-object;(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) .i.Find-members;(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. .i.Describe-participant;(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) .i.Describe-member ;(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. .i.Modify-profile;(ACCName participant, ACCName participant, Mods changes) -> Status Modify the personal profile of the named participant. .i.Download-news;(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 .i.Find-submissions;(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. .i.Accept;(ACCName participant, ACCName submission) -> Status Accept the specified submission. This has the effect of including it in the group activity. .i.Reject;(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. .i.Collapse;(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 .i.Create-group-activity;(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. FFS: Alias names. .i.Announce-group-activity;(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. .i.Suspend-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. .i.Delete-group-activity;(ACCName participant, ACCName activity) -> Status Delete the group activity from the system and notify members. .i.Add-member;(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. .i.Remove-member;(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. .i.Reject-subscription-request;(ACCName participant, ACCName request, Object notification) -> Status Reject a request for membership and notify the participant. .i.Modify-group-activity;(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. .i.Register-participant;(ACCName participant, ACCName new-participant, Attributes profile) -> Status Register the new participant as a participant in the service, or to modify the registration attributes. .i.Unregister-participant;(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. .i.Realisation of the Abstract User Functions; 10.1 .i.Distributed realisation of the computer conferencing service; 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 .i.Operations on master-copy-controlled activities; 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 % .i.Navigation of anÊAsynchronous Computer Conferencing Operation: 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 .i.Execution of an Asynchronous Computer Conferencing Operation: figure; 10.1.2.4 .i.Access control on master-copy-controlled activities; 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 .i.Operations on .i.non-master-copy-controlled activities; Figure % .i.Distribution of mocifications for a non-master-copy-controlled activity: 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 .i.Access control on non-master-copy-controlled activities; 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 .i.Communication between ACC-SA-s; Asynchronous Computer Conferencing Service Agents may locally within a company commu-nicate 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 % .i.Communication between ACC-SA-s: figure;.i.ACC-SA-s: Communication between, 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 % .i.Communication between ACC-SA-s: figure 10.1.5 .i.Distribution of new contributions; 10.1.5.1 Distribution for a .i.master-copy-distributed activity; 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 .i.Distribution from the responsible ACC-SA: figure 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 .i.Distribution when initially sent to a non-responsible ACC-SA: figure 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 .i.activity which is not master-copy- distributed; 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 % .i.Distribution to an activity which is not master-copy-distributed: 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 .i.UA with co-located single user store: figure Implementation 2: Integrated multi-user system with internal store, see figure 8. Figure 8 .i.Integrated multi-user system with internal store: figure Implementation 3: Integrated multi-user system without internal store, see figure 9. Figure 9 .i.Integrated multi-user system without internal store: figure 10.1.7 .i.Co-working with MHS;MHS coworking (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 .i.Co-location of IPM and Asynchronous Conferencing; 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 .i.Realisation of the Abstract User Functions; 10.3.1 Member port abstract user functions 10.3.1.1 .i.Find-activities (realisation); 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 .i.Find-subscribed-activities (realisation); 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 .i.Describe-activity (realisation); 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 .i.Subscription-request (realisation); 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 .i.List-news (realisation); 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 .i.Find-contributions (realisation); 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 .i.Find-notifications (realisation); 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 .i.Read-item (realisation); 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 .i.Mark (realisation); 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 .i.Submit-item (realisation); 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 .i.Withdraw-submission (realisation); 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 .i.Personal-reply (realisation); 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 .i.Add-attribute (realisation); 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 .i.Remove-attribute (realisation); 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 .i.Add-link (realisation); 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 .i.Remove-link (realisation); 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 .i.Delete-object (realisation); 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 .i.Find-members (realisation); 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 .i.Describe-participant (realisation); 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 .i.Describe-member (realisation); 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 .i.Modify-profile (realisation); 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 .i.Download news (realisation); 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 .i.Find-submissions (realisation); 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 .i.Accept and reject (realisation); 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 .i.Collapse (realisation); 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 .i.Create-group-activity (realisation); 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 .i.Announce-group-activity (realisation); 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 .i.Suspend-group-activity (realisation); 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 .i.Delete-group-activity (realisation); 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 .i.Add-member and remove-member (realisation); 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 .i.Reject-subscription-request (realisation); The reject-subscription-request user function is realised by the submission of a membership-decision notification. 10.3.3 .i.Administrator port abstract user functions; 10.3.3.1 .i.Modify-group-activity (realisation); 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 .i.Register-participant and unregister-participant (realisation); 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 .i.Routing (realisation); 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 .i.Abstract-bind and Abstract-unbind Operations; 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 .i.Abstract-bind-argument; 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. .i.ACCBindArgument ;::= 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 .i.Abstract-bind-result; .i.ACCBindResult ;::= 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 .i.Abstract-bind-errors; 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 .i.Abstract-unbind-operation; The ACC-Unbind abstract-unbind-operation is identical to the corresponding operation in X.413 | ISO/IEC 10021-5. 11.2 .i.Abstract-operations; 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 .i.Common data-types used in abstract-operations; 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 .i.Range; This attribute is defined identically to the corresponding attribute in X.413 | ISO/IEC 10021-5. 11.2.1.2 .i.Filters; 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 .i.Selector; 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. .i.Selector ;::= 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 .i.LinkChoice; 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. .i.LinkChoice ;::= SEQUENCE { starting-point [0] StartingPointList, link-arcs [1] LinkArcsList recursively [2] BOOLEAN DEFAULT TRUE } .i.StartingPointList ;::= 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 .i.Recursive LinkChoice: figure 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. .i.LinkArcsList ;::= 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 .i.Entry-information-selection; 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 .i.Entry-information; 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. .i.EntryInformation ;::= 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 } .i.AttributeValueCount ;::= SEQUENCE { type [0] ATTRIBUTE.&id ({AttributeTable}), total [1] INTEGER } 11.2.2 Format for forwarding items .i.Coding of objects;.i.Object coding format .i.ACCCodedObject ;::= CHOICE { entry-information [0] .i.EntryInformation;, - - as defined in X.413 but with X.acc attributes entry-content [1] .i.InformationObject ;- - 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 .i.IPM heading fields; When group communication objects are transported in the .i.InformationObject ;format (defined in X.420), then the IPM heading fields are used in the following way: IPM heading field ACC rep- resentat on 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 .i.heading extensions; 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 Sin le/ ult - val ed Cri- tic -lity 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 AccObjectDescr ptor 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 .i.ACC-Summarize abstract-operation ; 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 .i.ACC-List abstract-operation; 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 .i.ACC-Fetch abstract-operation; 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: .i.FetchArgument ;::= 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 .i.ACC-Register abstract-operation; The .i.ACC-Register abstract-operation ;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 .i.ACC-Register-argument; .i.ACC-Register-Argument; ::= 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 .i.Acc-submit abstract-operation; 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 .i.ACCContributionSubmissionArgument ;::= 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 .i.Acc-submit-result; Should the request succeed, the Acc-submit-result shall be returned. .i.ACCSubmissionResult ;::= 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 .i.Acc-submit Abstract-errors; 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. .i.AttributeError ;::= 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} } .i.AttributeProblem ;::= 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 .i.Fetch-restriction-error; 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 .i.Range-error; 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 .i.Security-error; 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 .i.Sequence-number-error; 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 .i.Service-error; 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 .i.Content-specific-error; 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 .i.ACC-Register-error; An ACC-Register-error reports a problem in an attempt to register information with the ACC. .i.ACCRegisterError ;::= ABSTRACT-ERROR PARAMETER SET { problem [0] RegistrationProblem, registration-type [1] RegistrationTypes } .i.RegistrationProblem ;::= 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. .i.Asynchronous Computer Conferencing Server Protocol (SA-SA- protocol, ACCSP); 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 .i.Reciept of objects from MHS distribution list; 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 .i.Special actions triggered by certain objects; 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 .i.Digests, special actions; 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 .i.Links. special actions; 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 .i.Accepted-contribution, special actions; 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 .i.Rejected-submission, special actions; 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 .i.Submissions to pre-moderated activities, special actions; 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) Om jag skall Šndra till speciell konferens fšr submissions, mŒste jag bl.a. sška efter submission-link, find-submission och acceptance- decision. 12.2.6 .i.Attribute-adder and attribute-subtractor, special actions; Attribute-adders and attribute-subtractors are redistributed in the same way as contributions. 12.2.7 .i.Object-inhibitor and object-burner, special actions; Object-inhibitors and .i.object-burner;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 .i.Presence-report, special actions; 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 .i.Subscription-change, special actions; 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 .i.Memberlist-finder, special actions; 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 .i.Update-distribution, special actions 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 .i.Routing-report-request, special actions 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 .i.dummy objects; 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 .i.Forward-item operation; 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. .i.ForwardItem ABSTRACT-OPERATION; 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)) .i.ForwardItemResult ;::= 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 .i.Transmission of objects between ACC-SA-s; 12.3.2 Transmission-modes .i.Transmission-mode; ::= 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): .i.acc-offering OBJECT CLASS; SUBCLASS OF acc-notification MUST CONTAIN { offer-list } MAY CONTAIN { transmission-mode - - proposed mode for stage 2 and 3 } ::= {acc-class-offering} .i.offer-list ATTRIBUTE; WITH ATTRIBUTE-SYNTAX OfferList MATCHES FOR ACC-EQUALITY SUBSETS ::= {acc-attribute-type 1} .i.OfferList ;::= SEQUENCE OF SEQUENCE { offered-object [0] ACCObjectName, is-it-a-dummy [1] AccDummy } .i.transmission-mode ATTRIBUTE; 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): .i.acc-request OBJECT CLASS; 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. .i.compound-mode ATTRIBUTE; WITH ATTRIBUTE-SYNTAX NULL MATCHES FOR EQUALITY ::= {acc-attribute-type 1} 12.3.4 Transmission in use-.i.ROSE mode; FFS (June 1993) (Priority = 1, June 1993) 12.3.5 Transmission in use-.i.DS mode; FFS (June 1993) (Priority = 1, June 1993) 12.3.6 Transmission in use-.i.DFR mode; FFS (June 1993) (Priority = 1, June 1993) 12.4 .i.ACC-Control-protocol; 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. .i.Control::= ABSTRACT-OPERATION; ARGUMENT ControlArgument RESULT ControlResult ERROR { InvalideParametersError, SecurityError, ServiceError, TemporalError } .i.ControlArgument ;::= 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. .i.ActivityControlArguments ;::= 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. .i.ControlResults ;::= 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 } .i.NegotiateControlArguments ;::= SEQUENCE {-- for further studies current-mode [0] TransferMode, acceptable-modes [1] SEQUENCE OF TransferMode, resource-limitation [2] SEQUENCE OF ResourceLimitationParameter OPTIONAL } .i.ResourceLimitationParameter ;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 } .i.NegotiateControlResults ;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. .i.NegotiateControlResults ;::= SEQUENCE { old-mode [0] TransferMode, new-mode [1] TransferMode, resource-limitation [2] ResourceLimitation OPTIONAL } .i.ResourceLimitation ;::= 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) } } .i.InterserverNADMessage ;is basically messages with accounting and token (= security related) information. .i.InterserverNADMessage ;::= SEQUENCE { messages [1] SEQUENCE OF NADM, accounting [2] SEQUENCE OF AccoutingInfo OPTIONAL tokens [3] SEQUENCE OF Token OPTIONAL } .i.ListTransferArguments ;::= SEQUENCE { list-information [1] ListInformation, accounting [2] SEQUENCE OF AccountingInfo, tokens [3] SEQUENCE OF Token } .i.ReadArgument ;::= SEQUENCE OF CHOICE { item [1] ItemReadArgument, activity [2] ActivityReadArguments } .i.ReadResult ;::= 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. .i.ItemReadArgument ;::= SEQUENCE { selector [1] ItemSelector, requested-attributes [2] EntryInformationSelection OPTIONAL } .i.ActivityReadArgument ;::= SEQUENCE { selector [1] ActivitySelectorList, requested-attributes [2] EntryInformationSelection OPTIONAL } .i.ActivityReadResult ;::= SEQUENCE { selector [1] ActivitySelector, requested [2] SEQUENCE SIZE(1 .. ub-items) OF EntryInformation OPTIONAL, activity-message [3] NADActivityMessage -- ActivityInfo } .i.ItemReadResult ;::= SEQUENCE { selector [1] ItemSelector, requested [2] SEQUENCE SIZE(1 .. ub-items) OF EntryInformation OPTIONAL, item [3] NADInterserverMessage -- NADInterserverMessage } .i.SearchArgument ;::= SEQUENCE { activity-range [0] ObjectId, selector [1] ItemSelector, requested-attributes [2] EntryInformationSelection OPTIONAL, filter [3] Filter } .i.SearchResult ;::= 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 Control: cancel object-inhibitor (object-burner) Control: Ihave offering Control: sendme 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 ACCContributionSubmissionArgumen t 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