isNonBinding (to be contract or not to be)

[James Bryce Clark <jbc@lawyer.com>]

The purpose of this blurb is to advance the discussion of the
"isNonBinding" parameter a bit, between conference calls.  I'd like to get
this resolved, one way or the other, in the next (Tuesday) metamodel call,
as we're running out of time.  

1.   The Issue:  

     a.     Standards Assertion:   Currently the BP Spec Schema states that
all logically completed binary transactions between parties legally binding
on the parties that conduct them.    See Sec 6.1 under subpara 2 "business
transaction".    (In this context, "logically completed" means a set of
messages in a request/response pattern that results in a "success" end state.)

     b.     Legal Assertion:     If we want to be able to offer the legal
effect of making the transactions binding, we need to create artifacts that
allow courts to support that solution.   Existing electronic signature laws
(including US, UN model, and EC rules) impose different requirements on an
electronic message in order to give it a legal character equivalent to a
manually signed writing.  They all share the need for some kind of token
indicator that can be understood as a voluntary indication of legal assent.
 One might reach that goal by (i) a prior written agreement among the
parties (such-and-such will be deemed a signature between us), or (ii) a
convention (such as a standard or a common practice).  

     c.     Standards Assertion:   Within ebXML,  XML-DSIG signatures are
already used, optionally, for assurance of sender identity and message
integrity.   We allow users to elect to use, or not use, DSIG by flipping
the "IsNonrepudiationOfReceiptRequired" toggle.   So we cannot use DSIG for
"legal signature" purposes.

     d.     Legal Assertion:  If we leave the BP SS the way it is, there's
a pretty good chance that courts will conclude that transaction messages
conducted over ebXML either (i) are always binding, as parties don't send
each other such messages unless they wish to do real deals, or (ii) are
binding only when a signature token is associated with them.   And there's
about even odds between the two.  So we haven't solved a problem for the
user base that I think we'd better solve.  One way is to declare in the
standard that all messages are intended to be binding.  The other is to do
something -- e.g., designate an exclusive document type or pattern type, or
create a parameter toggle -- that the parties are to use to indicate
binding status.  This message proposes the latter. 

     e.     Design Assertion:  The Acolytes of Haugen team (of which I am
one) put out a nonnormative "simple negotiation pattern" for a two party
collaboration which allows a set of terms (such as a CPA) to be negotiated
by a succession of offers-counteroffers.  In order for it to work, parties
must be able to send both nonbinding and binding transaction messages.  I
would like to preserve that functionality as I think (i) it works, (ii)
users will want to see that they can do something like this, and (iii) it
would also permit dynamic CPA formation from CPPs (as opposed to one party
selecting from the other's prefab sheaf of CPAs).  

     f.      Practical Observation:   Many EDI systems have the same
"default-on" or "only-on" legally binding character.  Some have "test"
parameters, which allow parties to send messages to each other without
binding effect.  As a practical matter, the granularity of a "test" toggle
is often all the way down to the individual message level. 

2.    The Proposal.   

This is a proposed text addition to the BPSS, that would add a new
parameter along with the nonrepudiation and similar toggles.  It is a
revised version of what I already sent around last week to a subset of the
metamodel team, and is a realization of the "binding" concept in the
"simple negotiation pattern" distributed in Vancouver.   

"6.2.7	Non-Binding

Trading partners may wish to indicate that a Business Transaction
transmitted as part of an ebXML arrangement is not intended to be binding.
E.g., parties may wish to send test sets to each other, or to exchange
proposed offers and counteroffers on a non-committal basis so as to
discover a possible agreed set of terms. When using tangible written
documents, parties often so indicate by providing or withholding a
signature, or using a "DRAFT" stamp.  However, in ebXML, the presence or
absence of an electronic signature cannot indicate legally binding assent,
because it is reserved for use as an assurance of sender identity and
message integrity.

The ebXML model assumes that Business Activities are intended by the sender
to be binding unless otherwise indicated.   When operating under this
standard, parties form binding agreements by exchanging binding messages
that agree to terms (e.g., offer and acceptance).    

The exclusive manner for indicating that a Business Activity is not
intended to be binding is to include a positive value for the Boolean
'isNonBinding' parameter in the requesting or responding activity.  That
positive value is a signal to the counterparty that the activity is only a
proposal or test, and that it may not rely on or seek to enforce the
activity."   

3.    MiniFAQ

    a.   Why "nonbinding" instead of "binding"?   So that the standard's
default is that messages are legally "live", not "duds".   That conforms
better to users' expectations and current EDI practice.  

    b.     What happens if a Binding request gets a nonBinding response
back?    Good question.  See paragraph 4 below.
    
4.   An Optional Addition

What happens if a Binding request gets a nonBinding response back?   We
introduce the possibility that a Binding substantive request message (like
an offer) may receive a nonBinding response (like acceptance).  

     nonbinding offer - gets nonbinding acceptance -- not binding, no 
     problem nonbinding offer - gets binding acceptance -- no problem; 
      BSI must interpret this as nonbinding, as both sides have to "sign 
        up" to get a contract
     binding offer - gets binding acceptance -- contract is formed, no 
      problem
     binding offer - gets nonbinding acceptance -- no contract.  But offer