International Telegraph and Telephone Consultative Committee
(CCITT)

Period 1989-1992

Question(s): 18/VII and 15/I	X.acc
Version 11
Annex B	COM VII
December 1992
Printed: 
Original: English

ENGLISH ONLY

Document MH-     	

SOURCE:	Group Communication editor, Jacob Palme, as instructed by the Nottingham meeting, June 1992 and the Oslo meeting, October 1992

TITLE:	X.acc Annes B: Mapping of the computer converencing service on MHS

SG I Associate Rapporteur on 
Group Communication:
Murray Turoff
New Jersey Institute of Technology
Newark, New Jersey 07102, U S A	%: +1-201-596 33 60
E-mail: Murray@eies2.NJIT.edu

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

INFORMATION TECHNOLOGY —
COMMUNICATION —
Message HANDLING Systems (MHS)
Part n: COMPUTER CONFERENCING
ANNEX A: Mapping of the computer conferencing service on mhs

CCITT Recommendation X.acc
ISO/IEC 10021-acc
Health Warning!
This document is an annex to the eleventh version of the Asynchronous Computer Conferencing Working Document X.acc. A number of versions of this document will be produced before the final draft recommendation. It has not been reviewed by either the SG VII or SG I Rapporteurs Groups. Do not base any implementations on this document.
Contents
Note: Annexes are text intended for the final version of X.acc. Appendices are text only included in the working document, and which will not go into the final version of X.acc in this format.
1	Introduction	1
2	Protocols defined	1
3	Relationship to the IPM content type	2
4	Mapping of CC Abstract Service Operations	5
4.1	Member port	5
4.1.1	Find-activities operation (not-mapped)	5
4.1.2	Find-indexed-object operation	5
4.1.3	Supply-index-key operation	5
4.1.4	Remove-index-key operation	5
4.1.5	Find-subscribed-activities operation (not-mapped)	5
4.1.6	Describe-activity operation (not-mapped)	5
4.1.7	Subscription-request operation (critical)	6
4.1.8	Unsubscribe operation (critical)	8
4.1.9	List-news operation (not mapped)	8
4.1.10	Find-contribution operation (not mapped)	8
4.1.11	Find-notifications operation (not mapped)	8
4.1.12	Read-item operation (not mapped)	8
4.1.13	Mark-as-seen operation (not mapped)	8
4.1.14	Mark-as-unseen operation (not mapped)	8
4.1.15	Submit contribution operation (non-critical)	9
4.1.16	Withdraw-submission (critical)	10
4.1.17	Personal reply operation (non-critical)	12
4.1.18	Modify contribution operation (non-critical)	12
4.1.19	Remove-item operation (critical)	13
4.1.20	Delete-item operation (non-critical)	13
4.1.21	Find-members operation (critical)	13
4.1.22	Describe-participant operation (critical)	14
4.1.23	Modify-profile operation (not mapped)	15
4.1.24	Download news operation (not mapped)	15
4.2	Moderator port operations	15
4.2.1	Find-submissions operation (not mapped)	15
4.2.2	Accept operation (critical)	15
4.2.3	Reject operation (critical)	16
4.2.4	Collapse operation	16
4.3	Conference management port operations	16
4.3.1	Create-group activity operation (not mapped)	16
4.3.2	Announce-group activity operation (non-critical)	17
4.3.3	Suspend-group activity operation (not mapped)	19
4.3.4	Delete-group activity operation (not mapped)	19
4.3.5	Add-member operation (critical)	19
4.3.6	Remove-member operation (critical)	20
4.3.7	Reject-subscription-request operation (critical)	20
4.3.8	Register-participant operation (non-critical)	20
4.3.9	Unregister-participant operation	20
4.3.10	Modify-group activity operation (not mapped??)	20

Annex B:	Mapping of ACC operations on the Message Handling System (MHS)
1	Introduction
General FFS: Security attributes must be added here and there.
Most people are not willing to have accounts in more than one message system. They want one single system to provide all their messaging services. This single system will in many cases be an MHS system mainly based on the IPM functionality. In order to provide Computer Conferencing services to such users, it is important 
(a)	that an MHS IPMUA without extensions should be able to submit and receivie group communication contributions. The contributions will then look like IPMessages sent via distribution lists to such MHS users.
(b)	that an MHS IPMUA can be extended with Computer Conferencing functionality. This paper proposes how this can be done by mapping the CCSA protocol on top of MHS.
The protocol provided for here is the CCSP protocol (Computer Conferencing Service Protocol), i.e. the protocol between different CC service agents. The protocol between a UA and a SA (Computer Conferencing Access Protocol, CCAP) is not provided for, since this mapping is assumed to be done locally, often within the MHS UA. Extension with support for the latter protocol is FFS.
Since MHS does not provide any support for the navigation phase (see chapter 10.2.2 of X.acc), it is assumed that necessary information for navigation is available locally.
Some of the GCSA operation are more naturally mapped on the Directory System (DS) operations. The provision of MHS mappings will however enable CC services also for users who do not have access to globally interconnected directory systems.
2	Protocols defined
Two new protocols are defined, the Pcc-non-critical and Pcc-critical. Both of these protocols are implemented as extensions of P22 using the heading extension mechanism available in P22. The difference between the Pcc-non-critical and the Pcc-critical protocols is that Pcc-non-critical protocol units can be delivered to a P22 UA. The P22 IPM-UA will then ignore those extended fields which it does not understand. The Pcc-critical protocol units should never be delivered to UA-s which cannot handle the Pcc-critical protocol. This effect can be achieved by using the same content type for Pcc-non-critical protocol units as for P22, but using a different content type for Pcc-critical protocol units. This means that even an MTS MTA without knowledge of CC services will be able to correctly handle Pcc operations.
Many of the P1 and P22 attributes may be used even if they are not mentioned here. For example, the P1 priority attribute may be used to gain higher speed in the transmission of a CC operation through the MTS.
The model assumed here is each CCSA keeps a store of group activities and contributions, not only originated in that GCSA but also everything which is used by participants connecting to that GCSA. This means that many of the CC operations can be performed using information available locally. Such operations need then not be mapped onto the CCSP protocol.
The advantage with this mode is a simpler CCSP protocol and faster user response times. The disadvantage is risks of inconsistencies between the information in different CCSA-s.
This does not mean that this should be the only mode of operation. Modes where less information is shadowed to CCSA-s, and where thus operations will more often require CCSP protokol operations between CCSA-s, are also possible.
FFS: Use of delivery notifications
3	Relationship to the IPM content type
The table below shows the relation between IPM attributes and computer conferencing contributions and links. When contributions are transported through the MTS, the contributions are mapped onto an IPM-like format, with IPM attributes instead of separate link objects.
IPM attribute	Optionality in IPM	Optionality in submissions	Optionality in accepted contributions	Representation in the CC abstract service	Comment	
this-IPM	Mandatory	Mandatory	Mandatory	cco-name attribute.	Name of the contribution. Globally unique except for some perverse messages imported from badly designed MHS systems.	
originator	OPTIONAL	Omission discouraged	Mandatory	cco-originator attribute.	Name of the UA which submitted this contribution to the MTS or to the CCS (whichever came first, in the case where the contribution is transported via the MTS to a CCSA).	
authorizing-users	OPTIONAL	OPTIONAL	OPTIONAL	separate link objects, one for each user.	Can be used when there are more than one author, or to indicate the human participant behind the originator role.	
IPM attribute	Optionality in IPM	Optionality in submissions	Optionality in accepted contributions	Representation in the CC abstract service	Comment	
primary-recipients	DEFAULT { }	Omission discouraged when there are such recipients.	Should be used if there are known such recipients. Same as posted-on.	separate link objects, one for each recipient, each referencing either a group communication activity, a participant or an MHS user or DL.	Umbrella name of group activity to which this contribution is primarily sent. Represented by a link object, not by an attribute of the contribution itself.	
copy-recipients	DEFAULT { }	Omission discouraged when there are such recipients.	Should be used if there are known such recipients. Same as posted-on.	separate link objects, one for each recipient, each referencing either a group communication activity, a participant or an MHS user or DL.	Umbrella name of group activity to which this contribution is sent as a copy for information.Represented by a link object, not by an attribute of the contribution itself.	
blind-copy-recipients	DEFAULT { }	Omission discouraged when there are such recipients.	Should be used if there are known such recipients. Same as posted-on.	separate link objects, one for each recipient, each referencing either a group communication activity, a participant or an MHS user or DL.	Umbrella name of group activity to which this contribution is sent as without informing recipients outside of this group activity. Represented by a link object, not by an attribute of the contribution itself.	
replied-to-IPM	OPTIONAL	OPTIONAL	OPTIONAL	separate link objects, one for each reference, each referencing either a contribution or some other kind of MHS message.	Name of a contribution to which the current contribution is a direct reply. Mainly to be used for inter-personal replies, replies in a group activity environment are represented by related-IPMs, see below.	
obsoleted-IPMs	DEFAULT { }	DEFAULT { }	DEFAULT { }	separate link objects, one for each reference, each referencing either a contribution or some other kind of MHS message.	Use as in X.420.	
related-IPMs	DEFAULT { }	DEFAULT { }	DEFAULT { }	separate link objects, one for each reference, each referencing either a contribution or some other kind of MHS message.	Name of a contribution to which the current contribution refers. This field should be used for replies in a forthgoing conversation within one or more group communication activities.	
IPM attribute	Optionality in IPM	Optionality in submissions	Optionality in accepted contributions	Representation in the CC abstract service	Comment	
subject	OPTIONAL	OPTIONAL	OPTIONAL	represented by the free-form-name in the cco-name.		
expiry-time	OPTIONAL	OPTIONAL	OPTIONAL	attribute as defined in X.420.		
reply-time	OPTIONAL	OPTIONAL	OPTIONAL	attribute as defined in X.420.		
reply-recipients	OPTIONAL	OPTIONAL	OPTIONAL	separate link objects, one for each recipient, each referencing either a group communication activity, a participant or an MHS user or DL.	This field is used to indicate where personal replies, intended only for the author of a contribution, are requested. The field does not indicate where group replies, intended for whole group activities, are requested to be sent. The latter is represented by the Followup-To attribute.	
importance	DEFAULT normal	DEFAULT normal	DEFAULT normal	attribute as defined in X.420.	Applies to all recipients, also via DL-s and group activities.	
sensitivity	OPTIONAL	OPTIONAL	OPTIONAL	attribute as defined in X.420.	Applies to all recipients, also via DL-s and group activities.	
auto-forwarded	DEFAULT false	DEFAULT false	Always TRUE	attribute as defined in X.420.	Used when a moderator forwards a submission to the moderated activity and for other uses as in X.420.	
extensions	DEFAULT { }	DEFAULT { }	DEFAULT { }	May vary from extension to extension (although all extensions in the 1992 version of X.420 are mapped by attributes as defined in X.420).	May vary from extension to extension.	
incomplete-copy	OPTIONAL	OPTIONAL	OPTIONAL	attribute as defined in X.420.	Use as in X.420.	
languages	OPTIONAL	OPTIONAL	OPTIONAL	attribute as defined in X.420.	Use as in X.420.	
auto-submitted	OPTIONAL	OPTIONAL	OPTIONAL	attribute as defined in X.420.	Use as in X.420.	
IPM attribute	Optionality in IPM	Optionality in submissions	Optionality in accepted contributions	Representation in the CC abstract service	Comment	
body	MANDATORY, but may be empty.	MANDATORY, but may be empty.	MANDATORY, but may be empty.	attribute as defined in X.420.	Use as in X.420.	
4	Mapping of CC Abstract Service Operations
4.1	Member port
4.1.1	Find-activities operation (not-mapped)
The find-activities operation has no CCSA protocol representation which can be mapped on MHS. Mappings will instead be provided using the Directory System (DS). Note however, that the Announce-group activity operation will enable the distribution of information about CC activities so that the information needed for the find-activities operation can be available locally.
4.1.2	Find-indexed-object operation
FFS: Not ready.
4.1.3	Supply-index-key operation
FFS: Not ready.
4.1.4	Remove-index-key operation
FFS: Not ready.
4.1.5	Find-subscribed-activities operation (not-mapped)
Information about which activities the user is a member of is available locally, so that no new GCSA operation is needed.
4.1.6	Describe-activity operation (not-mapped)
Information about Group Activities are distributed with the announce-group activity operation and the modify-group-activity operation. This information will thus be available locally, so that no CCSA operation is needed.
A mapping of the describe-activity operation on the Directory System may also be used.
FFS: How about statistics? Perhaps we should map this operation, it will then be similar to the Describe-participant operation below.
4.1.7	Subscription-request operation (critical)
The subscription-request operation is mapped as a Pcc-critical operation. This operation uses the following attributes:
Attribute	Originating protocol	Description	
Originator name	MTS	Name of the CCSA from which the request is sent.	
Recipient-name	MTS	Name of the group activity.	
DL-expansion-prohibited	MTS	Always set, since subscription requests are not to be distributed to other group subscribers.	
Content-type	MTS	Pcc-critical	
Subscriber-name	Pcc-criticial	Name of the member who wants to subscribe.	
Membership-action-type	Pcc-criticial	See CC abstract service definition. (Whether to be added or excluded from membership.)	
Membership-type	Pcc-criticial	See CC abstract service definition. (Member, moderator, observer, contributor, editor, indexer etc.)	
Operation-type	Pcc-non-criticial	Value = Subscription/withdrawal-request-operation	
Number-of-old-items-wanted	Pcc-criticial	Indicates what number of old items in the conference are to be presented as new to the new member.	
Time-limit-for-old-items-wanted	Pcc-criticial	All old items written after a certain time are wanted.	
Body	P22	Can be empty or optionally contain arguments for getting accepted as a subscriber. This text is to be read by the group activity manager.	
Security-parameters		FFS To be added	
Note: The operation above can also be used to change the status of a participant who already is a member.
The subscription-request result is mapped as Pcc-non-critical operation with the following attributes:
(FFS: This must be non-critical, since also IPM members should be notified when they become members or are excluded from membership.)
Attribute	Originating protocol	Description	
Originator name	MTS	Name of the group activity.	
Recipient-name	MTS	Names of participants who are to be notified about the new membership, such as the new member himself, the membership-requestor, the moderator, the manager and maybe all members of the activity. 
FFS	
DL-expansion-prohibited	MTS	Not set. If a DL issues a subscription-request, it is a DL implementation matter how to handle the result.	
Message-submission-time	MTS	Time when the membership change was registered with the group activity.	
Content-type	MTS	P22 extension	
originator	P22	If the subscription was accepted or rejected automatically, the name of the group activity is given here. If the subscription was accepted or rejected by a manager, the name of this manager is given here.	
Primary-recipients	P22	Name of the member.	
replied-to-IPMs	P22	IPM identifier of the subscription-request operation.	
related-IPMs	P22	IPM identifier containing the name of the membership link.
	
Status	Pcc-non-critical	Can have values accepted or rejected.	
Action-type	Pcc-non-critical	See abstract service specification. (Whether this is addition of a member or exclusion of a member.)	
Membership-type	Pcc-non-critical	See abstract service specification. (Kind of membership.)	
Operation-type	Pcc-non-critical	Value = Subscription/Withdrawal-request-result	
rejection-reason	Pcc-non-critical	Values: One of a list of possible rejection reasons. 
FFS	
body part 1	P22	Contains textual information corresponding to the Pcc-non-critical attributes, so that an IPM UA user is given this information. Can be empty if all recipients are CC UA-s.	
body part 2	P22	Can be empty or optionally contain reasons, given by a human group activity manager, for acceptance or rejection.	
Security-parameters		FFS To be added	
4.1.8	Unsubscribe operation (critical)
The Unsubscribe operation is mapped on the same protocol unit as the Subscription-request operation. The value of the Membership-action-type indicates whether this a subscribe or unsubscribe operation.
4.1.9	List-news operation (not mapped)
Since news is distributed using the MTS distribution mechanism, it is available locally and no GCSA operation is needed.
4.1.10	Find-contribution operation (not mapped)
Since contributions are distributed using the MTS distribution mechanism, they are available locally and no GCSA operation is needed. Note that the subscription-request-operation can be used for a new member of a group activity to request old entries in the activity to be delivered as new to him.
4.1.11	Find-notifications operation (not mapped)
Since notifications are distributed using the MTS distribution mechanism, they are available locally and no GCSA operation is needed.
4.1.12	Read-item operation (not mapped)
Since items are distributed using the MTS distribution mechanism, they are available locally and no GCSA operation is needed.
4.1.13	Mark-as-seen operation (not mapped)
Since items are distributed using the MTS distribution mechanism, they are available locally and no GCSA operation is needed to mark them.
4.1.14	Mark-as-unseen operation (not mapped)
Since items are distributed using the MTS distribution mechanism, they are available locally and no GCSA operation is needed to mark them.
4.1.15	Submit contribution operation (non-critical)
The submit-contribution operation is mapped as a Pcc-non-critical operation. This operation uses the following attributes:
Attribute	Originating protocol	Description	
Originator name	MTS	Name of the submittor.	
Recipient-name	MTS	Names of the group activities and/or IPM UA-s to which this contribution is submitted. After acceptance, this will be replaced by the recipients of the contribution within the group activity.	
DL-expansion-prohibited	MTS	Never set, since submissions are intended to be distributed to group activity members.	
Content-type	MTS	P22. Note that Pcc-non-critical cannot be used, since some of the members of the group may be IPM-UA-s.	
Other message-transfer-arguments	MTS	Used in similar ways as when forwarding IP-messages.	
originator	P22	Name of the submittor.	
primary-recipient, copy-recipients or blind-copy-recipients	P22	Names of the group activities and/or IPM UA-s to which this contribution is submitted. Note that both the submitted-to and posted-on are mapped in the same way. When sent from the originator to a group activity, this field value is submitted-to, when sent from the group activity to its members, this field value is posted-on.	
Recipient-name. notification-requests	P22	Same as in IPM, the request is handled by the UA-s of each individual member of the group activity.	
Recipient-name. reply-requested	P22	Same as in IPM, the request is handled by the UA-s of each individual member of the group activity.	
Replied-to-IPM, obsoleted-IPMs, related-IPMs	P22	Same as in IPM.	
Keywords	Pcc-non-critical	A list of search keywords for this contributions. If the group activity has an index, the contribution may be entered into the index under these keywords (and also under its subject).	
acceptance-decision	Pcc-non-critical	See abstract service specification. Indicates whether the submission has been accepted.
FFS: Note that this means that the Content is modified when distributing. Is that what we want?	
Request-for-acceptance-notification	Pcc-non-critical	Indicates that the submittor does want a notification when the contribution is accepted.	
Suppression-of-rejection-notification	Pcc-non-critical	Indicates that the submittor does not want any notification in case the contribution is rejected.	
Operation-type	Pcc-non-critical	Value = Submit-contribution	
Other P22 heading and body fields	P22	Used in similar ways as in IPM. If an already existing message or contribution is resent to this group, then the earlier message or contribution, including its heading, is included as a forwarded body part.	
Security-parameters		FFS To be added	
If the contribution is accepted by the group activity, it will then be sent out to the Messaging UA members of the group using the distribution list (DL) facility of MTS. This means that the P22 is unchanged, and that also most of the Message-transfer arguments are the same as when the contribution was submitted. Nested distribution lists may be used to optimize performance.
If the group activity is pre-moderated, and if the submittor is not a moderator, the submit-operation is forwarded via the MTS to the moderators, and it will not be sent out until accepted by the moderators. The group activity will store the submission, so that it can be sent out to the members when it has been accepted by the moderators.
FFS: Should the message be sent out to the members as a new MTS message, or as the same MTS message after DL forwarding? (a) For automatically accepted (b) for manually accepted items.
Rejection and acceptance notifications may also be sent, see descriptions below of the reject and accept operations.
FFS: If the contribution is autorejected, for example because it is too large, or the conversation depth limit is exceeded, what happens then. In the case of conversation depth limit, perhaps the contribution can be accepted but the conversation linearised?
4.1.16	Withdraw-submission (critical)
The withdraw-submission operation is mapped as a Pcc-critical operation. It can only be done on a contribution which has not yet been accepted by the moderator in a pre-moderated activity. This operation uses the following attributes:
Attribute	Originating protocol	Description	
Originator name	MTS	Name of the withdrawer.	
Recipient-name	MTS	Names of the group activities from which the submission is to be withdrawn. Also other recipients who are to be notified of the withdrawal can be included here.	
DL-expansion-prohibited	MTS	Set, since the withdrawal is never sent out to group activity members.	
Content-type	MTS	Pcc-critical.	
Other message-transfer-arguments	MTS	Used in similar ways as when sending IP-messages.	
originator	P22	Name of the withdrawer.	
primary-recipient, copy-recipients or blind-copy-recipients	P22	Names of the group activities and/or IPM UA-s from which the submission is to be withdrawn.	
Replied-to-IPM	P22	The IPM identifier of the submit-contribution operation to be withdrawn.	
Request-for-acceptance-notification	P22-non-critical	Indicates that the submittor does want a notification when the withdrawal is accepted.	
Suppression-of-rejection-notification	P22-non-critical	Indicates that the submittor does not want any notification in case the withdrawal is rejected.	
Operation-type	P22-non-critical	Value = Withdraw-submission-operation	
Body	P22	Can be used for a message to the moderator giving reasons for the withdrawal. Note however that withdrawal is not subject to moderator control, withdrawal is always accepted of the contribution itself has not yet been accepted by the moderator. 
(FFS???)	
Security-parameters		FFS To be added	
The result of the withdrawal is reported back to the withdrawer and to the moderators:
Attribute	Originating protocol	Description	
Originator name	MTS	Name of the group activity from which the contribution is withdrawn.	
Recipient-name	MTS	Names of the withdrawer and of the moderators of the group activity.	
DL-expansion-prohibited	MTS	Set, since the withdrawal is never sent out to group activity members. 
(FFS: Or are DL-s used for moderator lists??)	
Content-type	MTS	Pcc-critical.	
Other message-transfer-arguments	MTS	Used in similar ways as when sending IP-messages.	
originator	P22	Name of the group activity from which the contribution is withdrawn.	
primary-recipients	P22	Names of the withdrawer.	
copy-recipients	P22	Names of other members, usually the moderators, who are to be notified of the withdrawal.	
Withdrawn-contribution	Pcc-criticial	The name of the submit-contribution operation which was withdrawn. 
(FFS: Is this needed, information included in the Body see below.)	
Withdraw-operation	Pcc-criticial	The IPM Identifier of the withdraw-contribution operation causing the contribution to be withdrawn. 
(FFS: Is this needed, information included in the Body see below.)	
Operation-type	P22-non-critical	Value = Withdraw-submission-result	
Body	P22	The whole Withdraw-submission-operation is included here as a forwarded body part.	
Security-parameters		FFS To be added	
4.1.17	Personal reply operation (non-critical)
This is entirely identical to the corresponding IPM operation as mapped on the P22 protocol.
4.1.18	Modify contribution operation (non-critical)
FFS: Critical or non-critical?
FFS: Redo this section completely, using new concept of how contributions are modified. Text is modified by obsoletes, recipients by link objects, all other by some kind of notification.
The Modify-contribution operation is mapped in a format similar to the IPM forwarding format. The format is thus:
Modify-heading (P1 and P22)		
Modify-body	Original heading (P1 and P22), but incomplete-copy may be set	
	Original body, or, if incomplete-copy is set, no body	
FFS: When is incomplete-copy to be used?
The modify-heading may contain at least the following attributes: 
Attribute	Originating protocol	Description	
Originator name	MTS	Name of the modifier.	
Recipient name	MTS	Will contain all the recipients of the original contribution. May also contain additional recipients, for example if the modification includes re-sending of the contribution to additional recipients.	
Content-type	MTS	P22. Pcc-non-critical cannot be used, since also IPM UA-s should be able to receive the modification.	
originator	P22	Name of the modifier.	
Keywords	P22-non-critical	See submit-contribution.	
other P22 heading fields	P22	Can include additional recipients, since this is what the modification often is about. Can also include additional obsoleted-IPMs and related-IPMs. If the original contribution did not contain any replied-to-IPM, it can be added here.	
remove-recipient	P22-non-critical	Can be used if the modification is that the contribution is removed by a moderator for a post-moderated group.	
remove-reference	P22-non-critical	Can be used to remove replied-to-IPM, obsoleted-IPMs and related-IPMs from the original contribution.	
Operation-type	P22-non-critical	Value = Modify-contribution-operation.	
Security-parameters		FFS To be added	
If the modification is accepted, the modify-contribution is sent out to the members of the group activity just as an ordinary contribution.
The modifier is notified by getting his modify-contribution operation back again from the group. 
(FFS: Is this good??)
4.1.19	Remove-item operation (critical)
See Modify-contribution above. 
4.1.20	Delete-item operation (non-critical)
FFS: Maybe you can only delete an item by removing all links to it???
4.1.21	Find-members operation (critical)
The Find-members operation is mapped on The DS, not on the MHS
4.1.22	Describe-participant operation (critical)
The Describe-participant operation is mapped on Pcc-critical content, which is an extension of P22, as follows:
Attribute	Originating protocol	Description	
Originator name	MTS	Name of the participant who wants a description of another participant.	
Recipient-name	MTS	Names of the participants whose description is requested.
(FFS????)	
DL-expansion-prohibited	MTS	Always set.	
Content-type	MTS	Pcc-critical.	
Other message-transfer-arguments	MTS	Used in similar ways as when sending IP-messages.	
originator	P22	Name of the participant who wants a description of another participant.	
primary-recipient	P22	Names of the participants whose description is requested
(FFS????)	
Operation-type	Pcc-criticial	Value = Describe-participant-operation.	
target types	Pcc-criticial	See Abstract Service specification. (which attributes are desired.)	
Security-parameters		FFS To be added	
The result of the describe-participant operation is returned in the following format:
Attribute	Originating protocol	Description	
Originator name	MTS	FFS???????	
Recipient-name	MTS	Name of the requestor.	
DL-expansion-prohibited	MTS	Always set.
 FFS???	
Content-type	MTS	Pcc-critical.	
Other message-transfer-arguments	MTS	Used in similar ways as when sending IP-messages.	
originator	P22	FFS?????	
primary-recipient	P22	Name of the requestor.	
Operation-type	Pcc-criticial	Value = Find-participant-result.	
Describe-participant-result	Pcc-criticial	See Abstract Service specification. (Error or list of names and attributes)	
Security-parameters		FFS To be added	
4.1.23	Modify-profile operation (not mapped)
The personal profile of a participant is stored in his local CCSA and can only be modified via a local connection, so it need not be mapped on the CCSA protocol.
4.1.24	Download news operation (not mapped)
News is distributed via the MTS and available locally, so this operation does not need any CCSA protocol mapping.
4.2	Moderator port operations
4.2.1	Find-submissions operation (not mapped)
Submissions are sent via the MTS to the moderators, and are thus available locally to the moderators and need not be mapped.
4.2.2	Accept operation (critical)
The accept operation causes an accept notification to be sent to the contributor (if so requested by the contributor), to the other moderators and to the group activity itself. When the group activity receives this operation, it will send out the original submission (which it has stored) to the group activity members.
Attribute	Originating protocol	Description	
Originator name	MTS	Name of the moderator who accepts the contribution.	
Recipient-name	MTS	Name of the group activity and also name of the original submittor if the original submittor wanted an accept notification.	
DL-expansion-prohibited	MTS	Not set.	
Content-type	MTS	Pcc-critical.	
Other message-transfer-arguments	MTS	Used in similar ways as when sending IP-messages.	
originator	P22	Name of the moderator who accepts the contribution.	
primary-recipients	P22	Name of the group activity.	
copy-recipients	P22	Name of the original submittor, only if the original submittor wanted an accept notification.	
Acceptance-decision	Pcc-criticial	See abstract service specification.	
Operation-type	Pcc-criticial	Value = Accept/reject-submission-operation.	
related-IPMs	P22	Names of one or more accepted contributions.	
Security-parameters		FFS To be added	
The GCSA responsible for the group activity will then send out the original contribution, which it has stored, to its members including the other moderators.
FFS: Will and should members and moderators be told of the name of the accepting moderator? If so how?
FFS: Can delivery notifications be used?
4.2.3	Reject operation (critical)
See accept operation alternative A above. 
Note that an IPM UA can submit a contribution, but not receive any reject or accept notification. 
(FFS???)
4.2.4	Collapse operation
FFS: Not ready.MHS to be used.
4.3	Conference management port operations
4.3.1	Create-group activity operation (not mapped)
Group activities can only be created in the local CCSA of the creator or by other mappings of the CC services than the MHS mappings.
4.3.2	Announce-group activity operation (non-critical)
The Announce-group activity operation is mapped as a P22 extension operation. This operation has many similarities to the submit-contribution operation, since group activity announcements are distributed by sending them to other group activities and participants who might be interested in the activity.
Two possible formats can be used:
The simple format is used by the creator at the time of creation:
Announce-group-activity heading	
Announce-group-activity body	
The embedded format is used when an already created group activity is announced to additional recipients or recipient groups, possibly by someone else than the original creator.
Submit-contribution-heading (P1, P22 and Pcc-non-critical)		
Body	Announce-group-activity heading	
	Announce-group-activity body	
The attributes of the announce-group-activity heading and body are:
Attribute	Originating protocol	Description	
Originator name	MTS	Name of the announcer.	
Recipient-name	MTS	Names of the group activities and/or IPM UA-s to which this contribution is announced.	
DL-expansion-prohibited	MTS	Normally not set.	
Content-type	MTS	P22. Note that Pcc-non-critical cannot be used, since some of the recipients may be IPM-UA-s.	
Other message-transfer-arguments	MTS	Used in similar ways as when forwarding IP-messages.	
Message-submission-time	MTS	Creation time of the announced group activity.	
originator	P22	Name of the announcer.	
primary-recipient, copy-recipients or blind-copy-recipients	P22	See Submit-contribution operation above.	
Recipient-name. notification-requests	P22	See Submit-contribution operation above.	
Recipient-name. reply-requested	P22	See Submit-contribution operation above.	
Replied-to-IPM, obsoleted-IPMs, related-IPMs	P22	FFS ??????	
Modification update	P22-non-critical	This attribute is set, if the recipients already have got a previous announcement of the group activity, and are sent this new announcement to get an update of the group activity description.
FFS: Should be a per-recipient flag???	
Keywords	P22-non-critical	See Submit-contribution operation above.	
acceptance-decision	P22-non-critical	See Submit-contribution operation above.	
Request-for-acceptance-notification	P22-non-critical	See Submit-contribution operation above.	
Suppression-of-rejection-notification	P22-non-critical	See Submit-contribution operation above.	
moderation-policies	P22-non-critical	See X.acc chapter 8.4.	
anonymous-allowed	P22-non-critical	See X.acc chapter 8.4.	
hidden-members-allowed	P22-non-critical	See X.acc chapter 8.4.	
task	P22-non-critical	See X.acc chapter 8.4.	
non-members-can-submit	P22-non-critical	See X.acc chapter 8.4.	
membership-management-principles	P22-non-critical	See X.acc chapter 8.4.	
service-agent-restriction	P22-non-critical	See X.acc chapter 8.4.	
company-restriction	P22-non-critical	See X.acc chapter 8.4.	
length-limitations-on-contributions	P22-non-critical	See X.acc chapter 8.4.	
depth-limitations-on-conversations	P22-non-critical	See X.acc chapter 8.4.	
depth-shown	P22-non-critical	See X.acc chapter 8.4.	
suspension-time	P22-non-critical	See X.acc chapter 8.4.	
default-expiry-time	P22-non-critical	See X.acc chapter 8.4.	
activity-index	P22-non-critical	See X.acc chapter 8.4.	
moderator-list	P22-non-critical	See X.acc chapter 8.4.	
manager-list	P22-non-critical	See X.acc chapter 8.4.	
editor-list	P22-non-critical	See X.acc chapter 8.4.	
indexer-list	P22-non-critical	See X.acc chapter 8.4.	
open-for-list	P22-non-critical	See X.acc chapter 8.4.	
sub-activities	P22-non-critical	See X.acc chapter 8.4.	
super-activities	P22-non-critical	See X.acc chapter 8.4.	
Operation-type	P22-non-critical	Value = Announce-group-activity	
Body	P22	Contains a description of the scope of and topic of the new activity, to be used:
(a)	By prospective members to decide if they want to become members,
(b)	By members and moderator, to decide what to use the group activity for.	
Security-parameters		FFS To be added	
4.3.3	Suspend-group activity operation (not mapped)
A group activity can only be suspended by a local manager or using other protocols than the MHS mapping.
4.3.4	Delete-group activity operation (not mapped)
A group activity can only be deleted by a local manager or using other protocols than the MHS mapping.
4.3.5	Add-member operation (critical)
Could this not use the same format as used for the Subscription-request operation above?
4.3.6	Remove-member operation (critical)
Could this not use the same format as used for the Unsubscribe operation above?
4.3.7	Reject-subscription-request operation (critical)
See subscription-request-result above?
4.3.8	Register-participant operation (non-critical)
The MTS Register operation can be used without any changes (see X.411 section 8.4.1.1). That operation already contains an attribute Deliverable-content types which should include Pcc-non-critical and Pcc-critical for a CC UA.
4.3.9	Unregister-participant operation
FFS: Not ready.
4.3.10	Modify-group activity operation (not mapped??)
Since creation was not mapped, it is natural that also modification is not mapped on the MHS.
However, one might choose to send out a new Announce-group activity operation to recipients of the previous announcement, indicating the modified format of the activity. See the description of the Announce-group activity operation.