OMG Electronic Commerce 
Domain Task Force

Negotiation Facility Draft Initial Submission
This document is an initial submission in response to the OMG Electronic 
Commerce Domain Task Force, Negotiation Facility Request for Proposals.  










Proposal submitted by:
OSM SARL
In-line Software

Supported by:
Data Access Technologies
Fraunhofer Gesellschaft IML
Imperial College London
Ingenia s.a.

OMG doc. ec/98-06-02

Copyright 1998 by OSM sarl
The companies listed above hereby grant a royalty-free license to the Object Management 
Group, Inc (OMG) for worldwide distribution of this document or any derivative works 
thereof, so long as the OMG reproduces the copyright notices and the below paragraph on 
all distributed copies. The material in this document is submitted to the OMG for evaluation. 
Submission of this document does not represent a commitment to implement any portion of 
this specification in the products of the submitters. WHILE THE INFORMATION IN THIS 
PUBLICATION IS BELIEVED TO BE ACCURATE, THE COMPANIES LISTED ABOVE 
MAKE NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL INCLUDING 
BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 
FITNESS FOR A PARTICULAR PURPOSE. The companies listed above shall not be liable 
for errors contained herein or for incidental or consequential damages in connection with 
the furnishing, performance or use of this material. The information contained in this 
document is subject to change without notice.
The document contains information which is protected by copyright. All Right Reserved. 
Except as otherwise provided herein, no part of this work may be reproduced or used in any 
form or by any means (graphic, electronic, or mechanical, including photocopying, 
recording, taping, or information storage and retrieval systems) without the permission of 
one of the copyright owners. All copies of this document must include the copyright and 
other information contained on this page.
The copyright owners grant member companies of the OMG permission to make a limited 
number of copies of this document (up to 50 copies) for their internal use as part of the 
OMG evaluation process. RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure 
by government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Right in 
Technical Data and Computer Software Clause at DFARS 252.227.7013.

Contacts
Stephen J. McConnell
OSM sarl
20 rue Thibaud, Paris 75014, France
voice: + 33 1 4044 4116
mailto:mcconnell@osm.net
http://www.osm.net
Jack Greenfield
In-Line Software
45615 Willow Pond Plazza
Sterling Virginia 20164
voice: + 1703 925 5959
mailto: jack@inline-software.com
http://www.inline-software.com

Trademarks
All trademarks acknowledged
Contents
OMG Electronic Commerce  Domain Task Force  Negotiation Facility Draft Initial 
Submission	1
Contents	4
1.	Part 1	6
1.1.	Overview of the Submission	6
1.2.	Rationale	6
1.3.	Proof of Concept	6
1.4.	Resolution of RFP mandatory and optional requirements	7
1.4.1.	Negotiation Process	7
1.4.2.	framework	7
1.5.	response to RFP issues to be discussed	8
1.6.	Issues to be addressed	9
1.6.1.	Externalisation	9
1.6.2.	Aspects of the proposal that are incomplete or subject to 
synchronisation with related submission	9
2.	Part II, Proposed Specification	10
2.1.	Requirements	10
2.1.1.	Requirements Overview	10
2.1.2.	Technical Negotiation Requirements	10
2.1.3.	Commercial Negotiation Requirements	11
2.1.4.	Engagement and Release	11
2.2.	Overview	12
2.2.1.	Principal Entities and Processes	12
2.2.2.	Federation and Mediation of a Negotiation Process	13
2.3.	Object Model	15
2.3.1.	Negotiator	15
2.3.2.	Negotiation Process	16
2.3.3.	Federation Process	20
2.3.4.	Mediation Process	20
2.3.5.	Contractor	21
3.	Part 3,Compliance, CDL and IDL	24
3.1.	Summary of optional versus mandatory interfaces	24
3.2.	Proposed compliance points	24
3.3.	Complete CDL Specification	24
3.3.1.	Module ECLegal	24
3.3.2.	Module ECPolicy	25
3.3.3.	Module ECNegotiation	25
3.3.4.	Module ECContract	29
3.4.	Complete IDL Specification	30

1.	Part 1
1.1.	Overview of the Submission
1.2.	Rationale
Within electronic commerce, there exist requirements for the progressive and controlled 
disclosure of information between parties leading to mutual agreement.  This process is 
referred to as negotiation.  
The Negotiation Facility RFP issued by the Electronic Commerce Domain Task Force calls 
for proposals that defines a set of interfaces supporting:
? a business process or processes, expressed in IDL enabling multi-participant 
negotiation
? an object framework supporting dynamic negotiation policy substitution, policy 
verification, and interfaces through which domain policy can be used to control the 
disclosure of information and the decisions taken during the course of negotiation
This proposal addresses both of the above requirements through the specification of 
negotiation roles, negotiation business processes and negotiation policy based on the 
Business Object Component Architecture and Business Object Interoperability 
Specifications.
1.3.	Proof of Concept
The Negotiation Facility described in this submission is based on based on OSM’s business 
object platform whose design parallels the Combined Business Object Interoperability 
Specification.  Meta models used in the platform support BOCA style attribute and 
relationship and event definition.  
OSM SARL is working towards a commercial implementation of the Negotiation Facility and 
In-Line Technologies are working on a commercial implementation of a Business Object 
Interoperability Platform. Both In-Line and OSM are committed to convergence towards 
OMG adapted specifications in the areas of the Business Object Component Architecture 
and Business Object Interoperability Specifications. 
BOCA tools from Data Access Technologies have been used to validate CDL specifications 
used in this document.  
1.4.	Resolution of RFP mandatory and optional requirements
1.4.1.	Negotiation Process
? support for explicit declaration of agreement
 Explicit declaration of agreement using a policy named AcceptNegotiationPolicy.
? support for on-to-one and one-to-many negotiation
 One-to-one (bilateral) negotiation is implicitly supported by a negotiation process. One-
to-many (multilateral) negotiation is supported through mediation processes.
? support for collaborative and competitive negotiation
 No distinction is made between competitive versus collaborative negotiation, however, a 
distinction is made concerning the business system domain in which a negotiation 
process policy is soured.  This allows the federation of a negotiation process across 
multiple business domains and thereby enables assurance by a negotiator of 
observance of negotiation policy (i.e. responsibility of actions) and assurance that 
reciprocating negotiations are acting in accordance with the same policies (verification 
and accountability).
? support for the declaration of temporal constraints within a given negotiation context
 Temporal constraints are declared following any change in the state of a negotiation. 
Negotiation states are expressed as temporary states in which the state can expire. This 
allows time limited offers and responses during a negotiation.
? support for multi-level nesting of negotiation threads
 The proposed negotiation process is a BOCA process which itself allows the nesting a 
processes within processes. An issue to be addressed prior to a second submission 
concerns the chaining of subsidary negotiation failures and the effect of higher level 
negotiations.
? support for the synchronization of related or conditional negotiation threads
see above note.
1.4.2.	framework
? support for a primary or boot-strap negotiation process 
 The proposal provides a set of bootstrap extendable negotiation protocols including 
PROPOSE, REQUEST, OFFER, ACCEPT, ACCEPT_SUBJECT_TO_CONFIRMATION 
and REJECT.
? support for the dynamic substitution of one negotiation rule base with another 
negotiation rule base
 Rule substitution is achieved when the subject of a negotiation is itself a negotiation 
policy.  On agreement to use a subject negotiation policy, the subject can then be 
applied as policy of a new negotiation.
? verification and enforcement of rule conformance
Negotiation rules are expressed as policies which constrain the possible negotiating 
actions that a negotiator may do to a negotiation process.  Negotiation policies are 
expressed as BOCA dependant objects and as such may be introspected using MOF 
interfaces.  Through this mechanism verification is possible prior to issue and before 
commitment of a transaction by a negotiation process.
? interfaces supporting the introduction of domain policy at decision points in a 
negotiation process
Changes in a negotiation process are propagated to associated negotiators using the 
event propagation mechanisms as specified under BOCA.  Following notification, a 
negotiator is responsible for the invocation of a transition or related operation on the 
process.  Domain policy of the negotiator in determining an appropriate action as such 
is not within the scope of negotiation. However, the proposal defines two roles under 
which domain specialisation can be introduced.  These include the Negotiator and 
Contractor.
? interfaces supporting the introduction of domain policy at point in a negotiation process 
involving the release or disclosure of information
Disclosure policy is a policy applied by a role within a domain.  This specification treats 
the negotiator and contractor role interfaces as boundary points of the specification 
allowing the potential for subsequent generalised disclosure policies under a separate 
RFP.  This decision is in part related to the expected development of policy 
management interfaces under a Systems Management RFP.
1.5.	response to RFP issues to be discussed
? how agreement is established between participants within a negotiation process and 
how the explicit declaration of agreement could be used as input to the generation of 
evidence
A negotiation process state is expressed through a dependent negotiation policy.  Each 
policy contains a set of negotiation policies that may be applied to the negotiation 
process through a set-state operation. Each set_state operation causes the exchange 
of control from a primary to secondary negotiator (or the inverse) following which the 
cycle recommences.  At some point the cycle resolves to a terminal policy (i.e. a policy 
which has an empty set of transitions).  At this point a negotiation is closed in a 
possible agreed or rejected state.
The proposal provides a framework for contractual negotiation through the definition of 
a contract process.  A contract process allows the establishment of a set of obligations 
in a common scope (i.e. the contract is the scope of a set of obligations).  Each 
obligation references a contract and one contractor.  A contractor may have many 
obligations.  The structure of a contract is limited to dependant objects and as such are 
externalizable through the Life-Cycle extenalization interfaces. Interfaces supporting 
the externalisation of contracts (and contained obligations) are provided for purposes of 
evidence generation.  Interfaces under this specification leave the implementation of 
obligations and contract as open as possible but provide a framework for extension 
though the definition of an engagement and release policy types.  It is recommended 
that subsequent RFPs deal with particular policies concerning secure engagement.
? how local policy concerning information disclosure or decision processes are 
introduced within a negotiation, in particular, the ability of the facility to provide adaptive 
negotiation behaviour dependent on local policy of a participant within the negotiation 
process
Under the proposal adaptive behaviour within a given business system domain or 
policy domain is an implementation dependant feature.  Further interfaces are required 
at the level of generic policy management before such interfaces can be defined in a 
consistent way.
? the extent to which the subject of negotiation is separated from the process of 
negotiation
 A subject of a negotiation is known by reference only. The subject of a negotiation may 
be any object type, however, in practical terms is it expected that the negotiation 
subjects will frequently be dependant composite objects.
? submitters should discuss if and how their proposal can utilize the Trading Service, and 
if so, the extent to which standard properties are specified in the submission
The proposal is orthogonal to the Trading Service.  Offers under negotiation expresses 
the offer of an agreement whereas an offer in trader expresses an offer an interfaces 
as a source of service provision.  The relationship between Trader and a Negotiation 
Facilities is expected in the construction and modification of the subject of a negotiation 
which can itself be an interfaces and properties to be applied to a Trader.
? if directionality of negotiation is provided (i.e. a rule that distinguishes between a supply 
versus demand as opposed to symmetric agreement), the proposal should describe the 
aspects of the rule that support directionality
Directionality is supported in terms of source and destination of a negotiation 
expression (i.e. the source of a proposal as opposed to the receiver of the proposal).  
The specification does not imply that the issuer of a proposal is the issuer of the 
proposed subject.
1.6.	Issues to be addressed
1.6.1.	Externalisation
Explicit reference to life-cycle service may not be needed if this implied under BOCA.  
Currently the assumption is that the availability of life-cycle services is a dependant of a 
specific technology mapping of BOCA such as the Business Object Interoperability 
Specification.  This point will be raised with the respective submitters of the Business 
Component Architecture and the Combined Business Object Interoperability Specification.
1.6.2.	Aspects of the proposal that are incomplete or subject to 
synchronisation with related submission
Under this draft submission the following points are subject to finalisation:
1. declaration of constraints on possible negotiation policy transitions allowable within the 
scope of a negotiation in a given state
2. state sets on negotiation, mediation, federation, contract and obligation processes 
supporting open, closed and withdrawn negotiations (pending more detailed review of 
the Combined Workflow submission)
3. the possible consolidation of the negotiation, mediation and federation process into a 
single process type is being considered in order to simplify interfaces and support 
conceptual clarity of the submission
4. interfaces supporting access locking under a mediation have  not been included 
pending resolution of  point 3.
5. exceptions have not been included under this version


2.	Part II, Proposed Specification
2.1.	Requirements
2.1.1.	Requirements Overview
The OMG Electronic Commerce Domain Task Force (ECDTF) Negotiation Facility RFP 
identifies requirements for the progressive and controlled disclosure of information between 
parties leading to mutual agreement.  This process is referred to as negotiation.  The RFP 
separates requirements at a process and framework level by requesting a set of interfaces 
supporting:
? a business process or processes, expressed in IDL enabling multi-participant 
negotiation
? an object framework supporting dynamic negotiation policy substitution, policy 
verification, and interfaces through which domain policy can be used to control the 
disclosure of information and the decisions taken during the course of negotiation
This proposal addresses both of the above requirements through the specification of 
negotiators, negotiation, federation and mediation processes, and associated policies.  
Through these interfaces this proposal aims to establish a standard suite of negotiation 
policies across a broad industry community, through which different members of that 
community can engage in processes of collaborative negotiation.  The proposal maintains a 
consistently high priority on the requirement for independence between different business 
domains in the validation of it’s own actions (inferring responsibility), and, the validation the 
actions of the reciprocal parties (enabling assurance).
The proposal recognises three level of negotiation within the electronic commerce domain.  
The first and lowest level deals with the requirement for technical negotiation concerning 
enabling variable and dynamically configured level of operability between two different 
domains (characterised by an agreement concerning common security policies or the 
selection of mutually suitable payment instrument).  The second level deals with negotiation 
at a business level, a context characterised by the introduction of policies concerning 
information disclose, and the need for potentially long term, persistent and transactional 
characteristics in a negotiation.  The third level deals with the evolution from agreement to 
engagement wherein the subject of a negotiation is a legal artefact - inferring obligations 
and rights to participants. 
2.1.2.	Technical Negotiation Requirements
A negotiation facility is required to support the negotiated selection and configuration of 
supporting facilities across a set of independent domains involved in an electronic 
commerce transaction. Where commerce transactions require a common policy, 
mechanisms are needed to support the disclosure of service and facility availability and 
subsequent convergence to the selection of an agreed facility configuration. 
2.1.3.	Commercial Negotiation Requirements
As stated in the Joint OMG/CommerceNet Electronic Commerce Whitepaper, negotiation 
mechanisms allow a recursive interaction between consumer and dealmaker in the 
resolution of a “good deal”.  Solutions to the “good deal” are driven by independent 
business models of the respective parties.  Negotiation supports convergence or migration 
between two points of view on what a service should contain, and the contractual terms of 
engagement. Using mechanisms that allow for explicit or implied information by a 
consumer, it is possible to establish demand in terms of content or quality mix against price.  
The provider on the other hand, has interests in migrating a client towards established or 
available products.  The difference between the demand and supply references constitutes 
a vector of the difference between the two positions.  This vector can be used in the 
automation of negotiation processes leading to agreement and subsequent engagement 
between parties. Furthermore, this vector provides an indicator of the point of sale 
advertising required to move a client towards a provider’s products or services.  In a 
business to business model we are in effect dealing with multiple coexistent vectors where 
both sides have interests in moving towards potentially different directions.
 
Figure 0-1Supply and demand differential vectors during a negotiation process.
This proposal provides an extendable framework that explicitly enables the introduction of 
new rules of negotiation.  Furthermore, the specification enables interoperability between 
different negotiator implementation, and through this, the potential for the introduction of 
specialised policy “behind” the negotiator.  Negotiation policy manager is not addressed 
within the scope of this proposal.
2.1.4.	Engagement and Release
This proposal distinguishes between a negotiation through which agreement is reached, as 
opposed to a contract under which agreements are engaged, executed and enforced.  
Negotiators facilitate the reaching of an agreement, through the negotiation over a subject, 
whereas contractors enter into binding engagements to obligations through contracts.
In order to complete the cycle of commercial negotiation, the proposal introduces a set of 
general interfaces supporting contractors, obligations, contracts and policies defining 
minimal engagement and release policies.

2.2.	Overview
2.2.1.	Principal Entities and Processes
This proposal defines negotiators and contractor roles, mediation, negotiation, and 
federation processes, and supporting policies as the building blocks on which the 
Negotiation Facility is defined.  
Negotiators interact with negotiation entities in the definition of terms and conditions, and 
through policy, enable changes to a negotiable state.  The proposal identifies an extendable 
policy model for negotiation wherein the state of a negotiation is expressed through the 
negotiation policies associated to a negotiation process at any given point in time.  These 
negotiation policies constrain the behaviour of negotiators and mediators over the lifetime of 
a negotiation.
Negotiation processes represent a federation in which the members of the federation are 
negotiators and as such, all negotiators with a negotiation are bound to the same rules of 
negotiation for the duration of the negotiation.   Federation of a negotiation is enabled 
through negotiation federation process which are modelled as process adapters.  
Negotiation and federation processes are members of their respective management 
domains and as such are supported by local implementations.
A negotiation is a process that supports bilateral relationships between a primary and 
secondary negotiator.  Multilateral negotiation occurs when the number of members of a 
negotiation is greater than two. In such a case, a negotiation is considered to be a bilateral 
negotiation between a mediation process and another negotiator (or mediation process to 
mediation process). Aggregation policies at the level of the mediation process support 
consensus and majority aggregation. The principal role of a mediation process is to 
aggregate requests from multiple participants such that the aggregated result can be 
applied to a bilateral negotiation.
A negotiation may be offered, proposed, requested, accepted, agreed or rejected through 
an applied negotiation policy. A negotiation policy is an dependant composite object that 
contains a set of attributes that reflect the state of a negotiation and the possible negotiation 
policies that may be applied to the negotiation as replacements of the current negotiation 
policy.  This process of negotiation policy replacement is referenced here as a negotiation 
policy transition.
Negotiation policy values that enable migration towards negotiated agreement include:
? the REQUEST negotiation policy which allows transition to one of PROPOSE, OFFER 
or REJECT; 
? the PROPOSE negotiation policy which allows transition to one of REQUEST, 
REJECT, ACCEPT or AGREE (the availability of ACCEPT or AGREE being determined 
by an associated acceptance policy); 
? the OFFER negotiation policy which represent one half of an agreement which allows 
transition to one of ACCEPT, ACCEPT_SUBJECT_TO_CONFIRMATION or REJECT 
(the availability of ACCEPT or ACCEPT_SUBJECT_TO_CONFIRMATION are mutually 
exclusive);  
? the ACCEPT_SUBJECT_TO_CONFIRMATION negotiation policy which represents 
agreement, subject to the confirmation of the reciprocating party, and allows a 
transition to one of REJECT or ACCEPT;
? Both the ACCEPT and REJECT Negotiation Policies signify termination of a negotiation 
and do not support subsequent transitions, however, in the case of acceptance, 
subsequent engagement and release policies may be implied.
Policies described in this specification cover not only the constraints related to negotiation, 
but also rules concerning agreement context, mediation rules, negotiator privacy, access 
control and aggregation mechanisms. 
2.2.2.	Federation and Mediation of a Negotiation Process
Bilateral, single domain negotiation.
In the example shown below, two negotiators are participating in a negotiation within the 
same negotiation domain which implies the same business domain.  
 
Figure 0-1 Bilateral, single domain negotiation.

Federated Bilateral Negotiation
Federating a negotiation across multiple domains is achieved through a negotiation 
adapter.  A negotiation adapter acts as a proxy to the negotiation.  A negotiation adapter in 
a remote domain is enforced by the policy implementations of that remote domain.
 
Figure 0-1 Bilateral, federated negotiation.
Multilateral Negotiation
Multilateral negotiation is achieved through the introduction of a mediator. A mediator 
aggregates requests from member negotiators and applies the aggregated result to a 
negotiation in it’s capacity of a negotiator to the negotiation.  A mediation is one hand a 
negotiation process while at the same time participating as a negotiator to another process 
it is mediating.  Examples of mediated aggregation include auction or voting processes.
 
Figure 0-1  Multilateral single domain negotiation.
As in the case of federated negotiation involving policy implementations across different 
domains, the same model can be applied to the multilateral negotiation scenario.  
Multilateral Federated Negotiation
The following illustration shows a federated multilateral negotiation.  A negotiator and a 
mediation process represent the primary and secondary participants to the negotiation.  The 
negotiation is federated through an adapter (a federation process) into the domain of the 
mediator.  The mediation process meditates requests from two negotiators, one within the 
domain of the mediator and another in an external domain.  The external negotiator is 
supported through a local federation process, which in this case is adapting the mediator 
process.
 
Figure 0-1 Multilateral, federated negotiation.
As shown through the above sequence of illustrations, the negotiation facility enables 
distributed multilateral negotiation, through which, each participant is supported through 
independent implementations of a negotiation facility within a local business system 
domain.
2.3.	Object Model
2.3.1.	Negotiator
Negotiator is an entity that supports the creation of and interaction with negotiation, 
mediation and federation processes.

	entity Negotiator {
		process Negotiation {
			relationship owned_by IsPartOf Negotiator;
			relationship primary References Negotiator;
			relationship secondary References Negotiator;
			[required] attribute NegotiationPolicy status;
			[required] attribute PrivacyPolicy privacy_policy = PublicPrivacyPolicy;
			[required] readonly attribute MediationPolicy mediation_policy;
			[required] attribute any subject;
			[required] readonly attribute TimeBase::UtcT creation_date_time;
			[required] readonly attribute TimeBase::UtcT issued;
			[required] readonly attribute TimeBase::UtcT changed;
			[required] readonly attribute TimeBase::IntervalT lifetime;
			[required] readonly attribute ActiveNegotiatorValue active;
			{ mediation_policy = BilateralMediationPolicy; };
			// contract state set to be done: open, closes, suspended
		};
		relationship negotiations Aggregates Negotiation;

		process Mediation : Negotiation {
			relationship mediates Adapter Negotiation;
			relationship represents Aggregates Negotiator;
			{ mediation_policy = MultilateralMediationPolicy; };
			attribute AggregationPolicy aggregation_policy;
			attribute short quorum;
		};
		relationship mediations Aggregates Mediation;
	
		process Federation : Negotiation {
			relationship federates Adapter Negotiation;
			relationship negotiator References Negotiator;
		};
		relationship federations Aggregates Federation;
	};
};

2.3.2.	Negotiation Process
A Negotiation is a specialisation of BocaProcess.  A negotiation is lauched by a 
negotiator. A negotiation process has relationships to an initiating negotiator, one primary 
and one secondary Negotiator. A negotiation process provides explicit support for bilateral 
negotiation.  This characteristic is exposed through the mediation_policy attribute, which 
returns the constant keyword BILATERAL (note, as described later, the bilateral 
characteristic of a negotiation may be overridden through a mediator process acting in the 
capacity of a reciprocating negotiator). 
A negotiation process has as attributes the subject of the negotiation, issued and 
changed times, the lifetime of the negotiation under it’s current state. The state attribute 
holds a dependant NegotiationPolicy which defines constrains of the negotiation. The 
attributes privacy_policy contain a PrivacyPolicy declaration which constrains the ability to 
traverse relationships across a negotiation process.  The mediation_policy for a 
negotiation is a constant BilateralMediationPolicy. These values of these attributes 
constitute the terms and conditions of a negotiation.

		process Negotiation {
			relationship owned_by IsPartOf Negotiator;
			relationship primary References Negotiator;
			relationship secondary References Negotiator;
			[required] attribute NegotiationPolicy status;
			[required] attribute PrivacyPolicy privacy_policy = PublicPrivacyPolicy;
			[required] readonly attribute MediationPolicy mediation_policy;
			[required] attribute any subject;
			[required] readonly attribute TimeBase::UtcT creation_date_time;
			[required] readonly attribute TimeBase::UtcT issued;
			[required] readonly attribute TimeBase::UtcT changed;
			[required] readonly attribute TimeBase::IntervalT lifetime;
			[required] readonly attribute ActiveNegotiatorValue active;
			{ mediation_policy = BilateralMediationPolicy; };
			// contract state set to be done: open, closes, suspended
		};

PrivacyPolicy
PrivacyPolicy is an abstract dependent that may be specialised to enable the creation of 
new privacy policies.
This specification defines PublicPrivacyPolicy and PrivatePrivacyPolicy whose value 
attribute may be one of PUBLIC or PRIVATE. If the value is PUBLIC the relationships 
traversal is allowed. If the value is PRIVATE traversal of negotiator relationships is disabled.

	[is_abstract] dependent PrivacyPolicy : ECPolicy::Policy {
	};

	dependent PublicPrivacyPolicy:PrivacyPolicy {
		{value = PUBLIC; };
	};

	dependent PrivatePrivacyPolicy:PrivacyPolicy {
		{ value = PRIVATE; };
	};

NegotiationPolicy
A negotiation may exist in an offered, proposed, requested, accepted or rejected state 
depending on the value of a NegotiationPolicy. A negotiation policy contains a value 
attribute that reflects the state of the negotiation. The principal function of a negotiation 
policy is to declare valid transition and negotiation subject change constraints within a 
declared negotiation context.
Value is a string that corresponds to the name of the policy. The transitions attribute holds 
a list of negotiation policies that a negotiator may request a transition to.  A transition 
corresponds to a change in the value of the negotiation policy referenced by the state of the 
negotiation process. The access_control attribute defines access control constrains 
enforced by the get_subject and set_subject operations of Negotiation process.   The 
access control value contains a value attribute whose value may be one of the enumerated 
values GET, UPDATE and SET. The GET value requires subject assessor methods to 
restrict access to a read-only. UPDATE extends privileges to enables changes to the 
features of the referenced object. A value of SET extends privileges to allow the 
replacement of the value of the subject attribute. 

	[is_abstract] dependent NegotiationPolicy : ECPolicy::Policy {
		[required] readonly attribute Set<NegotiationPolicy> transitions;
		[required] readonly attribute SubjectAccessControlValue access_control;
	};

	[is_abstract] dependent AbstractAccept : NegotiationPolicy {
	};

A set of abstract negotiation protocols are defined as a basis for an extendable set of 
working negotiation policies.  The abstract set includes NegotiationPolicy, AbstractOffer, 
and AbstractAccept. 

	[is_abstract] dependent AbstractOffer : NegotiationPolicy {
	};
	[is_abstract] dependent AbstractAccept : NegotiationPolicy {
	};

A bootstrap set of bootstrap policies are defined under which possible transitions and 
access constraints are reconfigured.  These policies include two terminal policies  
RejectNegotiationPolicy and AgreeNegotiationPolicy and four transitional policies 
ConditionalAccept, OfferNegotiationPolicy, ProposeNegotiationPolicy and the 
RequestNegotiationPolicy.
	Reject Policy
The RejectNegotiationPolicy signifies rejection of the terms and conditions of the 
negotiation and is a terminal policy (	as transitions are available).

	dependent RejectNegotiationPolicy : NegotiationPolicy {
		{ value = REJECT; };
		{ access_control = GET_SUBJECT; };
		//{ transitions = { }; }; // needs to be intialised as an empty list
	};

	Accept Policy
The AcceptNegotiationPolicy is a terminal negotiation policy that signifies agreement to 
the terms and conditions of the negotiation.

	dependent AcceptNegotiationPolicy : AbstractAccept {
		{ value = ACCEPT; };
		{ access_control = GET_SUBJECT; };
		//{ transitions = { }; }; // needs to be intialised as an empty list 
	};

	Conditional Accept Policy
ConditionalAcceptNegotiationPolicy is a transitional policy that signifies conditional 
agreement to the terms and conditions of a negotiation.  This policy type may be confirmed 
through transition to the AcceptNegotiationPolicy or rejected through transition to 
RejectNegotiationPolicy.

	dependent ConditionalAcceptNegotiationPolicy : AbstractAccept {
		{ value = CONDITIONAL_ACCEPT; };
		{ access_control = GET_SUBJECT; };
		//{ transitions = { AcceptNegotiationPolicy, RejectNegotiationPolicy }; };
	};

	Offer Policy
OfferNegotiationPolicy expresses non-negotiable terms and conditions.  An OFFER may 
be accepted through a policy transition of the type AbstractAccept or rejected through a 
policy transition to a RejectNegotiationPolicy.

	dependent OfferNegotiationPolicy : AbstractOffer {
		{ value = OFFER; };
		{ access_control = UPDATE_SUBJECT; };
		//{ transitions = { AbstractAccept, RejectNegotiationPolicy }; };
	};

	Propose Policy
ProposeNegotiationPolicy expresses one half of an agreement.  A proposal also reflects 
flexibility by the issuer to the reception of an alternative expressed through the 
RequestNegotiationPolicy. The ProposeNegotiationPolicy may also be accepted 
through a transition to a policy of the type AbstractAccept or rejected through transition to 
the RejectNegotiationPolicy. The combination of ProposeNegotiationPolicy and 
RequestNegotiationPolicy enables recursive exploration of the negotiation subject 
between negotiators.
	
	dependent ProposeNegotiationPolicy : AbstractOffer {
		{ value = PROPOSE; };
		{ access_control = SET_SUBJECT; };
		//{ transitions = { RequestNegotiationPolicy, AbstractAccept }; };
	};

	Request Policy
RequestNegotiationPolicy expresses a interest by the issuing negotiator in receiving a 
offer corresponding to the  subject of the negotiation. RequestNegotiationPolicy allows 
transition a policy of the type AbstractOffer, or may be rejected through transition to the 
RejectNegotiationPolicy.  Under the RequestNegotiationPolicy the subject of the reply 
may be changed or replaced by the reciprocating negotiator. The combination of 
RequestNegotiationPolicy and the AbstractOffer ProposeNegotiationPolicy enables 
recursive exploration of alternative negotiation subjects between negotiators.
	
	dependent RequestNegotiationPolicy : NegotiationPolicy {
		{ value = REQUEST; };
		{ access_control = SET_SUBJECT; };
		//{ transitions = { AbstractOffer, RejectNegotiationPolicy }; };
	};

The policy transition lists referenced in the above form a connected graph in which the 
policy constraints applicable to a negotiation can be transitioned from one set to another.  
The set of policy values list provides a policy transition model that can be considered as the 
state transition diagram.  The following illustration depicts the possible policy transitions 
enabled by these policy values when the acceptance policy is implict (i.e. the 
AbsrtractAccept policy is of the type AcceptNegotiationPolicy).
 
Figure 0-1 Transition diagram based on implicit acceptance.
The following illustration depicts the possible policy transitions enabled by these policy 
values when the acceptance policy is subject to confirmation (i.e. the AbstractAccept policy 
is of the type ConditonalAcceptNegotiationPolicy).
 
Figure 0-2 Transition diagram based on conditional acceptance.
2.3.3.	Federation Process
The Federation process is a process launched by a negotiator. It adapts a Negotiation 
process to the local implementations of negotiation and privacy policies.  

		process Federation : Negotiation {
			relationship federates Adapter Negotiation;
			relationship negotiator References Negotiator;
		};

2.3.4.	Mediation Process
Mediator is a type of negotiation that can be launched by a negotiator.  A mediator process 
aggregates policy change requests from a group of negotiators down to a single mediated 
request based on a aggregation policy.  A mediator is a negotiation from the perspective of 
a negotiator, however, the interfaces declares a mediation policy of MULTILATERAL 
indicating mediated behaviour in the resolution of negotiation policy.

		process Mediation : Negotiation {
			relationship mediates Adapter Negotiation;
			relationship represents Aggregates Negotiator;
			{ mediation_policy = MultilateralMediationPolicy; };
			attribute AggregationPolicy aggregation_policy;
			attribute short quorum;
		};

A mediator acts an aggregation point between n negotiators and a negotiation process. A 
mediator overrides the mediation_policy of a negotiation by providing the constant 
keyword MULTILATERAL

	type MultilateralMediationPolicy:MediationPolicy {
		{ value=MULTILATERAL; };
	};

A mediator process is responsible for the pooling of transition requests received through the 
set state and invoking an aggregation of the pooled request on the negotiation entity once 
one of the following events has occurred:
? all attached mediated negotiators have issued transition request;
? the negotiation expires, causing the aggregation of request based on the request 
received
In both cases, the number of member negotiators must be above a quorum value 
associated with the mediation process.  The quorum value represents the minimum number 
of negotiators required before transition request will be accepted.  The aggregation 
mechanism to be applied to pooled transition requests is defined through an 
AggregationPolicy available through the aggregation_policy interface of a mediator.  
AggregationPolicy is an abstract type that has a value attribute which characterises the 
aggregation model.  An aggregation policy provides the abstract aggregate interface, which 
takes as input a collection of pooled transition requests and returns an aggregated request.  
CensensusAggregationPolicy and MajorityAggregationPolicy are specialisations of the 
abstract aggregation policy and provides concrete aggregation mechanisms corresponding 
to the following two values: CONSENSUS and MAJORITY.

	[is_abstract] type AggregationPolicy : ECPolicy::Policy{
		const CORBA::PolicyType CONSENSUS =1011;
		const CORBA::PolicyType MAJORITY =1012;
		NegotiationPolicy aggregate();
	};
	type ConsensusAggregationPolicy:AggregationPolicy{
		{ value=CONSENSUS; };
	};
	type MajorityAggregationPolicy:AggregationPolicy{
		{ value=MAJORITY; };
	};

Following the aggregation of pooled transition request, a mediation process invokes the 
aggregated request against a set_state interface of the negotiation process.
2.3.5.	Contractor
This proposal distinguishes between a negotiation through which agreement is reached, as 
opposed to a contract under which agreements and engaged, executed and enforced.  
Negotiators facilitate the reaching of an agreement, through the negotiation over a subject, 
whereas contractors enter into binding engagements to obligations through contracts.


	entity Contractor {
		relationship represents RoleOf ECLegal::LegalEntity;  // review CBO's 
		process Obligation;
		process Contract {
			relationship obligations Aggregates Obligation;
			[required] readonly attribute short reference;
			[required] readonly attribute string title;
			[required] readonly attribute short version;
			[required] readonly attribute TermsAndConditions terms;
			[required] readonly attribute TimeBase::UtcT creation_date_time;
			[required] readonly attribute TimeBase::UtcT issued;
			// state set to be included
		};
		process Obligation {
			relationship contracts Aggregates Contract;
			relationship contractor References 1..1 Contractor;
			readonly attribute TermsAndConditions terms;
			[required] readonly attribute EngagementPolicy engagement_policy;
			[required] readonly attribute ReleasePolicy release_policy;
			// note, process specifications for engage, release and dispute
			// to be extended in connection with Workflow interfaces
			process engage {  }; 
			process release {  }; 
			process dispute {  }; 
			process withdraw { 
				[required] readonly attribute string reason;
			};
		};
		relationship obligations Aggregates Obligation;
	};

Contract
A Contract process is launched by a contractor and provides as a mechanisms though 
which Obligations are aggregated.  

		process Contract {
			relationship obligations Aggregates Obligation;
			[required] readonly attribute short reference;
			[required] readonly attribute string title;
			[required] readonly attribute short version;
			[required] readonly attribute TermsAndConditions terms;
			[required] readonly attribute TimeBase::UtcT creation_date_time;
			[required] readonly attribute TimeBase::UtcT issued;
			// state set to be included
		};

Obligation
Obligations define the relationship between a Contractor and a Contract.
An obligation infers a responsibility.  The extent of responsibility inferred by a obligation is 
undefined, however, the specification includes the declaration of the state of an obligation 
(as distinct from the state of a contract).

		process Obligation {
			relationship contracts Aggregates Contract;
			relationship contractor References 1..1 Contractor;
			readonly attribute TermsAndConditions terms;
			[required] readonly attribute EngagementPolicy engagement_policy;
			[required] readonly attribute ReleasePolicy release_policy;
			// note, process specifications for engage, release and dispute
			// to be extended in connection with Workflow interfaces
			process engage {  }; 
			process release {  }; 
			process dispute {  }; 
			process withdraw { 
				[required] readonly attribute string reason;
			};
		};

3.	Part 3,Compliance, CDL and IDL
3.1.	Summary of optional versus mandatory interfaces
Submissions must clearly distinguish interfaces that all implementations must support from 
those that may be optionally supported.
To be identified in a subsequent release.
3.2.	Proposed compliance points
Submissions should propose appropriate compliance points for implementations.
1. Mandatory requirements include the provision of the negotiator interface in it’s entirety. 
This shall constitute level 1 compliance, thereby providing technical negotiation.
2. Implementations supporting the contractor interface in it’s entirety shall constitute level 
2 compliance, thereby providing commercial negotiation support.
Changes or extensions required to adopted OMG specifications
No changes or extensions to adapted OMG specification are required by this 
specification.
3.3.	Complete CDL Specification
A complete CDL listing is provided under ec/98-06-03 in modules:
3.3.1.	Module ECLegal 
Note that the existence of a legal entity is required across multiple electronic commerce 
application areas beyond negotiation such as electronic payment and brokerage.  These 
interfaces remain very general at this stage in order to facilities discussions with the 
Security SIG concerning explicit requirements for X509.R3 certification as a de-facto norm 
in the electronic commerce domain.  The proposal will seek appropriate mechanisms 
through which security policy and technology policy may be appropriately exposed through 
a legal entity interface.

module ECLegal {
	entity LegalEntity {
		// subject to CBO review
	};
};

3.3.2.	Module ECPolicy 
CORBA 2.2 defines a set of policy interfaces that meet requirements for the declaration and 
enforcement of POA behaviour.  This proposal extends these interfaces for use in the 
declaration of constraints to applied in the establishing and maintaining of federated policy 
domains (i.e. a domain in which the equivalent policy is enforced).  However, until such time 
that policy management facilities are introduced under the OMG, the usage of policy infers 
a strong dependence on future standards. As such, the usage of the CORBA::Policy 
interface is raised as a discussion issue.

module ECPolicy {
	type Policy : CORBA::Policy {
		readonly attribute string value; 
	};  // Negotiation Facility extendable policy
};

3.3.3.	Module ECNegotiation 

module ECNegotiation {
	const CORBA::PolicyType PUBLIC=1001;
	const CORBA::PolicyType PRIVATE=1002;
	const CORBA::PolicyType REJECT=1003;
	const CORBA::PolicyType ACCEPT=1004;
	const CORBA::PolicyType CONDITIONAL_ACCEPT=1005;
	const CORBA::PolicyType OFFER=1006;
	const CORBA::PolicyType PROPOSE=1007;
	const CORBA::PolicyType REQUEST=1008;
	const CORBA::PolicyType BILATERAL=1009;
	const CORBA::PolicyType MULTILATERAL=1010;
	[is_abstract] dependent PrivacyPolicy : ECPolicy::Policy {
	};
	dependent PublicPrivacyPolicy:PrivacyPolicy {
		{value = PUBLIC; };
	};
	dependent PrivatePrivacyPolicy:PrivacyPolicy {
		{ value = PRIVATE; };
	};
	enum SubjectAccessControlValue{ // review with SSIG
		SET_SUBJECT,
		UPDATE_SUBJECT,
		GET_SUBJECT
	};

	
	[is_abstract] dependent NegotiationPolicy : ECPolicy::Policy {
		[required] readonly attribute Set<NegotiationPolicy> transitions;
		[required] readonly attribute SubjectAccessControlValue access_control;
	};

	[is_abstract] dependent AbstractAccept : NegotiationPolicy {
	};

	[is_abstract] dependent AbstractOffer : NegotiationPolicy {
	};

	// note : transition is current under resolutioin concerning the 
	// defintion of constraints over transition list content and element types

	dependent RejectNegotiationPolicy : NegotiationPolicy {
		{ value = REJECT; };
		{ access_control = GET_SUBJECT; };
		//{ transitions = { }; }; // needs to be intialised as an empty list
	};

	dependent AcceptNegotiationPolicy : AbstractAccept {
		{ value = ACCEPT; };
		{ access_control = GET_SUBJECT; };
		//{ transitions = { }; }; // needs to be intialised as an empty list 
	};

	dependent ConditionalAcceptNegotiationPolicy : AbstractAccept {
		{ value = CONDITIONAL_ACCEPT; };
		{ access_control = GET_SUBJECT; };
		//{ transitions = { AcceptNegotiationPolicy, RejectNegotiationPolicy }; };
	};

	dependent OfferNegotiationPolicy : AbstractOffer {
		{ value = OFFER; };
		{ access_control = UPDATE_SUBJECT; };
		//{ transitions = { AbstractAccept, RejectNegotiationPolicy }; };
	};




	dependent ProposeNegotiationPolicy : AbstractOffer {
		{ value = PROPOSE; };
		{ access_control = SET_SUBJECT; };
		//{ transitions = { RequestNegotiationPolicy, AbstractAccept }; };
	};

	dependent RequestNegotiationPolicy : NegotiationPolicy {
		{ value = REQUEST; };
		{ access_control = SET_SUBJECT; };
		//{ transitions = { AbstractOffer, RejectNegotiationPolicy }; };
	};

	dependent MediationPolicy : ECPolicy::Policy {
	};

	type BilateralMediationPolicy:MediationPolicy {
		{ value=BILATERAL; };
	};

	type MultilateralMediationPolicy:MediationPolicy {
		{ value=MULTILATERAL; };
	};

	enum ActiveNegotiatorValue { PRIMARY, SECONDARY };

 	[is_abstract] type AggregationPolicy : ECPolicy::Policy{
		const CORBA::PolicyType CONSENSUS =1011;
		const CORBA::PolicyType MAJORITY =1012;
		NegotiationPolicy aggregate();
	};

	type ConsensusAggregationPolicy:AggregationPolicy{
		{ value=CONSENSUS; };
	};

	type MajorityAggregationPolicy:AggregationPolicy{
		{ value=MAJORITY; };
	};



	entity Negotiator {
		process Negotiation {
			relationship owned_by IsPartOf Negotiator;
			relationship primary References Negotiator;
			relationship secondary References Negotiator;
			[required] attribute NegotiationPolicy status;
			[required] attribute PrivacyPolicy privacy_policy = PublicPrivacyPolicy;
			[required] readonly attribute MediationPolicy mediation_policy;
			[required] attribute any subject;
			[required] readonly attribute TimeBase::UtcT creation_date_time;
			[required] readonly attribute TimeBase::UtcT issued;
			[required] readonly attribute TimeBase::UtcT changed;
			[required] readonly attribute TimeBase::IntervalT lifetime;
			[required] readonly attribute ActiveNegotiatorValue active;
			{ mediation_policy = BilateralMediationPolicy; };
			// state set to be done: open, closes, suspended
		};
		relationship negotiations Aggregates Negotiation;

		process Mediation : Negotiation {
			relationship mediates Adapter Negotiation;
			relationship represents Aggregates Negotiator;
			{ mediation_policy = MultilateralMediationPolicy; };
			attribute AggregationPolicy aggregation_policy;
			attribute short quorum;
		};
		relationship mediations Aggregates Mediation;
	
		process Federation : Negotiation {
			relationship federates Adapter Negotiation;
			relationship negotiator References Negotiator;
		};
		relationship federations Aggregates Federation;
	};
};




3.3.4.	Module ECContract

module ECContract {
	const CORBA::PolicyType IMPLICIT_ON_LAST_ENGAGEMENT=1011;
	const CORBA::PolicyType IMPLICIT_ON_LAST_RELEASE=1012;
	dependent TermsAndConditions {
	};
	dependent EngagementPolicy : ECPolicy::Policy {
	};

	dependent DefaultEngagementPolicy : EngagementPolicy {
		{ value = IMPLICIT_ON_LAST_ENGAGEMENT; };
	};
	dependent ReleasePolicy : ECPolicy::Policy {
	};
	dependent DefaultReleasePolicy : ReleasePolicy {
		{ value = IMPLICIT_ON_LAST_RELEASE; };
	};

	entity Contractor {
		relationship represents RoleOf ECLegal::LegalEntity;  // review CBO's 
		process Obligation;

		process Contract {
			relationship obligations Aggregates Obligation;
			[required] readonly attribute short reference;
			[required] readonly attribute string title;
			[required] readonly attribute short version;
			[required] readonly attribute TermsAndConditions terms;
			[required] readonly attribute TimeBase::UtcT creation_date_time;
			[required] readonly attribute TimeBase::UtcT issued;
			// state set to be included
		};








		process Obligation {
			relationship contracts Aggregates Contract;
			relationship contractor References 1..1 Contractor;
			readonly attribute TermsAndConditions terms;
			[required] readonly attribute EngagementPolicy engagement_policy;
			[required] readonly attribute ReleasePolicy release_policy;
			// note, process specifications for engage, release and dispute
			// to be extended in connection with Workflow interfaces
			process engage {  }; 
			process release {  }; 
			process dispute {  }; 
			process withdraw { 
				[required] readonly attribute string reason;
			};
		};
		relationship obligations Aggregates Obligation;
	};
};

3.4.	Complete IDL Specification
IDL Files
A complete IDL listing is provided under ec/98-06-04.idl in modules:
module ECLegal
module ECPolicy
module ECNegotiation
module ECContract

NEGOTIATION FACILITY – DRAFT INITIAL SUBMISSION
	PAGE 20