OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes Draft from the OASIS Legal XML Member Section Electronic Contracts Technical Committee


Folks,

Below are the draft minutes of the May 21, 2003 conference call. In my
attempt to capture the conversation I doubtlessly introduced errors. I
also created a lot of text. In order to maintain the benefits of brevity
along with a record of how our collective thinking evolved, I have
included a summary at the beginning of the minutes.

Please let me know if you find any errors or misattributions.

Thanks,

Dave Marvit
Fujitsu Labs of America
dave@marvit.org 
---------------------------------------
Minutes 
OASIS LegalXML eContracts Technical Committee
May 21 2003 Conference call

Summary:
- ODR and Construction Contracts were moved until the June 4th call. 
- Dave Marvit was unanimously elected co-vice chair.
- The ABA will be appointing an OASIS representative in early June. This
will create an administrative contact we can work with. John Messing
will send email to the list when that happens.
- The minutes were approved subject to the revision that on July 16 the
law firm contract creation and negotiation will be discussed.
- Dr. Leff presents his 'click-through contract' scenario.
- It is agreed that John Messing, with Dan's help, and possibly Rolly's
help, will work on a scenario for electronic conflict of interest
detection and management.
- Dan moved: We should indicate: "For every issue we surface we will
determine if it is transactional or it relates to the contract content.
The assumption is that we will be biased towards contract content, but
will keep track of the other data. We will explicitly make the decision
as to what will be included in the standard at the end of the scenario
review process." Dr. Leff seconded the motion and it was unanimously
approved.
- Proceedings, ABA and San Francisco discussions were deferred until the
next meeting. 
-------------------------


Body of May 21, 2003 Minutes

The following members of the committee were present:

Zoran Milosevic
Jason Harrop
Dave Marvit
Dr. Leff
Peter Meyer
Barry Hansen
Dan Greenwood
John Messing
John McClure
Sergio Maldonado


Note: Because Rolly couldn't make the call, the decision was made (by
acclamation) to move the discussion of ODR and construction contracts,
to June 4, and move the contract litigation to the end of the queue. Dr.
Leff's click through contracts will be added to today's agenda as item
#3.

Dan Greenwood nominated Dave Marvit to be the successor to Eddie O'Brien
as Co-Vice Chair. Jason Harrop seconded. The motion was unanimously
approved 

John Messing: (Interjecting) The ABA will be naming an OASIS
representative around mid June. When that happens the representative
will have a staff person to help them. That should facilitate
coordination.

DG: Could you send us an email when that happens?

John Messing: No problem.

Approval of minutes:

Jason: Could the minutes be amended to indicate that on July 16 the law
firm Contract creation and negotiation will be discussed?

Dave: Sure

DG: We can vote on minutes as amended, and then send it to the list.

DM: So moved
DG Seconded
Approved by acclamation

DG: Up to now we have done administrative work. Finally, we move on to
substance. Finally... Dr. Leff...?

(Dr. Leff presents his Click-Through Contracts scenario)
Dr. Leff: We have prepared a DTD for handling click-through contracts.
We have all been to web sites, gotten agreements, clicked 'I agree' and
downloaded software.

We have collected some examples of these agreements and abstracted out
the key points someone would want to search for.

The first question is why do this in XML? If a corporation has a lot of
people downloading software and clicking on contracts, they are
obligating the company. The company would want to know what people are
agreeing to.

There needs to be some signed applet that stores the contracts locally,
and there must be a system so the lawyers can search by clause type on
the contracts to which his company has agreed.

An actual DTD is out there. It includes terms such as the name of the
software vendor, name of software, agreeing party. There is also a
preamble and a substance section, a choice of Law, liability waiver, and
some specialized tags (such as munitions control and internal use
restrictions that only apply if the US government downloads and do not
apply to anyone else).

All of thee tags have been put into Jason's format, and are in the
documents folder for the TC. 

The scenario is that people will be downloading these, agreeing to
contracts in XML, the applet will be putting it into special places on
the hard-drives, and then the data will be searched by the corporate
council - so they can find out what agreements have been made.

John Messing: So this is for reporting and data-mining the obligations
and ramifications of downloads by the corporate community?

Dr. Leff: Yes

DG: It is maddening not being able to certify how many or what contracts
the corporation, or government organization has been obligated to. Also
for consumers and small businesses, they should be able to know and keep
track of their obligations. Now it is hard to even know how to save this
stuff. So there is a bit of a consumer and small business angle. Still,
the big corporations will be the driver.

John Messing: There might be other applications. This could cover any
type of agreement. For law firms (for example) this kind of model has
applications in conflict analysis... A big firm has to make sure that a
new client is not in a conflicting position with another client. For
large firms this can be tough. A litigation client requires a fairly
complex conflict analysis.

Imagine that Dr Leff sued you, Dan. He was represented by a partner in
my firm. At another time, Dan sues Dave regarding an entirely different
matter. But we can't represent Dan because that's a conflict with Dr.
Leff.

If you get into an online consumption and provision of legal services
-click wrap or something more sophisticated - keeping track of the
conflicts can be very difficult. 

If the law firm takes on both matters then it might have to get out of
both matters.

I suspect that there are other applications as well.

Zoran: Can we specify these patterns of conflict?

Dr. Leff: Doesn't the law case management systems that already exist
have the info required to handle this? I understand how important this
is, but does XML need to be involved? We only need the XML if
heterogeneous systems are involved.

John Messing: My point is merely that the opportunity for data-mining of
contracts in real-time has applications well beyond click-through
contracts.

Sergio: This seems like a good choice because click-through contracts
are very specific and nicely extensible.

DG: The idea of going through each scenario is so that we can do factual
analysis so that we can set requirements wisely. I think it would be a
good approach if you, John, put together a separate scenario for the
issue of conflict management.

John Messing: Rolly would know more.

DG: Sure, but could you champion it. I'd be happy to help out. As for
the click-through contract situation, there is a great deal of
similarity. There is a different group of contracts for representation
that are similar to one another, but quite different from the click
through contracts. So, it would be helpful if they were a represented in
a separate scenario.

Jason: I thought that the main point that John was making was NOT merely
taking care of all of the conflict searching, but the intersection
between conflicts and online business services. When you offer services
to everyone who might go to your web site -- say John Q. public who
wants a $100 divorce -- this is where you need to do the conflict
analysis. The customer may agree to the terms of service. Then you need
to do the conflict analysis.

John McClure: Does the scenario have anything to do with presentation of
the contract?

Dr. Leff: Yes and No.  We are assuming that the presentation will be a
function of the XML. We do provide a facility for the company to go from
an ASCII format into the XML format. In essence we are dealing with an
ASCII presentation format. In our case we are going from a realm where
there already is a presentation and going into XML.

John McClure: So is the contract stored in XML?

Dr. Leff: Yes.

John Messing: Is the tool being used (the applet) outside the standards
process?

Dr. Leff: Yes, of course. We provided that in the scenario for context.
The conversion is not intended to be part of the standard, or an issue
for the TC.

John McClure: How do you describe the information model that your tags
describe?

Dr. Leff: It is not so sophisticated. It is basically a sequence of
tags. It does not have the complexities of conditional relationships and
temporal relationships between clauses.

DG: Putting my hat on as government council - a lot of the contracts
have the same title. As corporations collect these it becomes an issue
to be sure that as hundreds or thousands of these are collected it
becomes important to have a unique identifier for each contract.

At least within the domain of implementation, the company needs a unique
identifier. I am not so concerned about the implementation now.

Also, we will need some date to be specified.

Barry: Does that need to be in the standard, or is that a function of
the software that puts the date there? Is the execution date (and the
stuff outside the contract) in scope or not?

DG: I don't have an answer, but having a date in most contracts is
standard, But these are contracts of adhesion. We will probably need to
support signatures and dates in some way -- even though they aren't
represented in all kinds of electronic contracts.

Jason: It is a fact that is there in the background. The scenario
clearly needs the time and date the person clicked on the contract.
There is an overlap between this scenario and the contract management
scenario. We can all agree that the time should be noted, but it does
not necessarily need to be part of the contract.

DM: What exactly is a contract?

Jason When you say you agree to a click through contract you agree to
what you saw, not to an underlying XML representation. If there is a
dispute and there is a question of the time, well, that's an issue of
fact. Typically the date thing is outside the representation of the
contract.

Peter: The date is when you installed the software in some cases. In
those cases it becomes a question of fact.

Zoran: It helps to see the time and the signature as evidentiary because
the contract exists independent of them. They exist as evidence of the
agreement, but the agreement exists independently of that.

John McClure: But it can be very helpful.

Peter: We need to figure out what should be in the standard. There are
an arbitrary number of pieces of additional information that might be
included. So what is in or out of scope?

John McClure: There is a distinction between agreements and contracts.
Agreement only occurs when all parties have signed. So having a single
signature and date does not tell you that the contract has been agreed
to.

Zoran: I think we are talking about differing things. There is contract
template and contract instance.

Barry: I have been following this and I think I didn't express this
well. I was thinking that the date is not included in the representation
of what I clicked on. So, when we think about scope, are we dealing with
other pieces of data that are not necessarily part of the contract? For
example, we keep info on the location of the paper copy. (Such as
'filing cabinet eight on the third floor'.) That wouldn't be part of the
standard, but it is useful metadata. It is relevant data, but I wouldn't
expect to see that as part of the standard. So, with this in mind, how
broad is the scope?

DG: It seems that from the scoping discussions we've had so far... we
want information on the contract formation side that goes beyond the
contract itself. Also, on the contract management side, we want
information which goes beyond the scope of the contract itself. So I
feel comfortable including this.

John McClure: Can we solve this problem by allowing other standards
based XML tags into the standard? If the problem is addressed by another
standardized namespace, why not use that?

DG: I'd like to keep going on the scenario. We've got the parties; we
have the terms and conditions. Does anyone object to splitting off John
Messing's law firm example off? 
(No objections heard.)

DG: Then we got into the idea that there should be a unique identifier
for each contract. Then we agreed that date and time are useful, and
that many people would want to include it. But there was also a view
that it was out of scope.

Then the question came up 'What is the contract itself?' That is a big
issue in terms of this scenario.

The final thing I'd add is that it would be useful to have a more
granular markup. What is the return policy, what is the revenue
recognition and so on.

Ought this standard assume 1. that the contracts are like a blob (an
HTML or PDF document) and people would download them in that form and
XMLify, or that 2. the users would put them into XML, or that 3. the big
company would be putting the contract into XML with this DTD to begin
with?

Dr. Leff: The software has already been written to put the contract into
XML from ASCII. The software makes no distinction as to who does this.

Sergio: This is a very good application. Much as we now have P3P for
privacy, this could apply in a similar way. The question of do you sign
the image or the essence. There is a lot of scope for that discussion.

DG: The P3P perspective assumes that one use would be for the web site
to put the agreement into the XML format. Should we think that's the
only way? Or would there be other ways for people to apply this?

Sergio: We can't assume that everyone will be putting their contracts
into this format. There may be a role for intermediates here. 

John McClure: If we were to adopt the court filing envelope that might
contain an agreement.

John Messing: Court filing 1.1 is being abandoned for 'court filing
blue'. The issues of merging with some of the other standards (court
filing TC) will be tricky, but are in the air.

You'd have a base 64 encoded representation of the 'blob'. You sign the
blob using XML-DSig. That's one way.

DG: How about the e-notary TC?

John Messing: No, that committee has been in mothballs for a while. And
before it was mothballed, it was still not appropriate.

Jason: It seems to me that the way that is likely to work is that, for a
while at least, the XMLization is likely to happen at the vendors end.
The licensee is likely to see an html or text document. Only after our
standard is established will the licensee generate demand to receive the
contract in XML.

More generally, I'd question the idea that the corporate council wants
to see all of the licenses that the employees have agreed to. Right now
the councils don't want to know because there is a question of agency.
Imagine that I work for Mercedes and I get a click-through contract that
says I will forgo all patent cases. Well... Mercedes isn't going to
grant that agency. The corporation doesn't want to acknowledge that it
is bound by all of these contracts.

It will more likely be: I Jason Harrop, want to agree to the following
contract, but before I do it has to be signed off by someone who has the
appropriate authority. If it is benign then perhaps software can decide
and I can sign off myself.

DG: I take your point. Triggering a process, for approval or something
else, would be useful. But still, I'd want this kind of system. If I've
been informed of an agreement then I can send off an email message
repudiating it. While I know what you are saying, I think your statement
that it is the only way it would be implemented is too strong.

DG: Our final work product hasn't been determined yet. But in my mind I
imagine that we will be producing some kind of implementation guide that
will help with these tough issues. For example, if date and time don't
make it in then we will be able to address it there. The point is that
we will be able to address issues without including them in the standard
proper.

Jason: I think we need to specify which bits of scenarios will be
addressed in the standard and which parts will be addressed in other
surrounding materials.

John McClure: I agree that there will be certain workflow issues. This
will be addressed by documents being an offer. The point is that there
are different document types. We could say that a legal contract is
represented inside a legalXML envelope. This would necessarily be a
presentation format. Whereas a contract and offer doc doesn't
necessarily have a presentation form.

DG: Jason suggested that we should provide an indication as to weather
the business requirements should be encompassed inside the standard or
outside. The idea of triggering a workflow is an example of something
that should be outside the standard itself.

I would assume that the unique ID would be inside the standard.

Second is date and time: I think we need to return to that. We have it
tagged as an issue and I personally don't have a conclusion. I think
that's unsettled.

The other two are:
- An accurate representation of the contract and

- A markup of the basic sections of the contract.

Jason: I'd put the unique ID in the meta information bucket. It could be
in the wrapper or in the contract document somehow. I would think that a
unique ID for a contract is not part of the contract in any legal sense.

DG: I am comfortable with your characterization, but I still think there
should be a tag providing a unique ID for each file.

John McClure: Are we exchanging an agreement? And if so...

DG: At the point agreement is manifest, then that needs to be captured
(what was agreed to). There needs to be an ID for that.

John McClure: The identifier you are referring to, is it for the
document exchanged between the vendor and the customer? Or is it for the
contract? If there is a purchasing contract that this is made subject
to...

DG: You mean other documents incorporated by reference?

John McClure: Yes

DG: You think that there should be an UID for every agreement?

John McClure: Yes

DG:  Hmmm... Ok.

John McClure: I am trying to make a distinction between an agreement and
the contract.

DG: What I'm saying is really simple. I go to a site and it has 18
paragraphs. Why isn't that a contract? What else is there?

McClure: The web page represents the document that is being assented to.
The identifier reefers to the web page (the URL for the web page)?

DG: Oh... I am talking about just the contract itself. I download a web
page that has text inside a scroll-box. You should be able to get just
the text inside the scroll. I'd like to have a UID so I can look at that
contract later -- know what it is that I'd agreed to. Is that
responsive?

Dave: Are you suggesting that the ID be globally unique?

DG: It wouldn't bother me if the ID was not globally unique.

Jason: It would be quite useful though. Imagine two large organizations
merging. It s preferable if the identifiers have a good chance of being
unique. We have to ask 'what is the business requirement for doing so?'

DG: I have noticed that many of these documents [click through
contracts] have the same name. I want to be able to see, for example,
who the parties are.

John Messing: The question is how do we help people get useful
information from the documents. A document ID could be useful in many
ways, but we need to be able to have the specific business case.

Peter: We seem to be talking about the markup of the terms of the
document (that will become a contract when assented to) and then the
various kinds of documents representing the contract. Some times these
documents will be a complete representation of the contract and
sometimes they will not be.

How often will the XML markup remain relevant after the contract
artifact is generated? I'd suspect that it will remain relevant only in
limited cases.

The other thing that is being contemplated is having an envelope that is
used when moving these contract artifacts about. This is quite a
different issue.

I am wondering if this entire scope can be handled by one TC.

DG: I agree. I think that the purpose of the scenarios is to see if we
are being under or over inclusive in our efforts. Do you think we should
scale back to some representation of the contract at the time it was
clicked on?

Peter: My personal view is that we should be focusing on the markup of
the terms. If we try to do more we will be too far ahead of the
technology and the market. We will end up as an interesting piece of
academic work.

DG: I don't disagree with anything that was said, but I'd like to hear
other views.

John Messing: I tend to agree with Peter. The discussions are so
interesting I tend to get lost. I think it is important to remain
focused on the objective.

DG: Perhaps we should be applying Jason's razor to keep defining what is
inside and outside the contract. Then we can decide later what to
include.

John Messing: Yes, but we need to be careful that we don't do something
useless. We can keep two separate lists. We can keep a list of what is
inside and a list of what may be required outside. Then we can look at
the stuff inside and work on an agreement. Then we can examine the
outside terms and decide what we need to include.

Peter: That seems spot on.

DG: That is appealing because I feel like we can actually achieve
something this way.

Zoran: I like Jason's original proposal - some information is common to
most contracts (names, parties). Resolve that and then get into
implementation choices.

DG: It sounds like everyone who has spoken believes that we should stay
as focused as we can on the contract itself.

Dr. Leff: 1. The whole issue of the transportation of the contract -
this was reviewed by the secure contract container. (More information is
available on the resources page). 2. The other scenario I sent out,
litigation and eContracts, looks at the relationship between the
contract and eBXML. That is an interesting issue. When we get to that
scenario it might be a good time to look at that issue.

On the GUID issue, at least in the case of the click through contract,
the title may be the same, but the product name will be different.
(Think about the same lease being used for different addresses.)

DG: Before we get to that, can I see if there is agreement on the basic
scope question. Do people agree that there should be basic focus on the
content of the contract itself? Does anyone disagree?

Jason: I am wondering weather the question should be weather we give the
envelope description to a different committee, or hold on to it for
later. If nobody has a need for it now then it is reasonable to hold on
to it. On the other hand, if people need it now, then we can pass it on.

Peter: Let's hold on to it for now. Let's keep track of the
'transactional' data.

DG: A motion might be ripe. Maybe we should indicate: For every issue we
surface we will determine if it is transactional or it relates to the
contract content. The assumption is that we will be biased towards
contract content, but will keep track of the other data. We will
explicitly make the decision as to what will be included in the standard
at the end of the scenario review process.

DG: Moves
Dr Leff: Seconds

Approved unanimously.

DG: In view of what we just said, I think the scenario gets a lot easier
to define. The transactions and the license don't change. 
-The UID, date, and Time get tagged as transactional. (If there is a
date in the content of the contract then it goes to the other side of
the ledger.)
- Transportation is clearly transactional.
- The basic sections of the contracts (liability, choice of law, and
other basic terms) are inside the content of the contract.
- Finally we had the idea that there would be some kind of container.
Perhaps we would model it on the court filing envelope, or an IETF
standard. But we would have a container for the blob that would be the
presentation form of the contract. This would be a representation of the
presentation of the contract.

Can we leave the last point as open? ["Is the presentation transactional
or content or something else?"]

DG: Perhaps we should open up the next meeting with the minutes and have
the scenario in a votable form?

Dr. Leff: I am not clear on what am I supposed to do?

Dg: I was hoping that the group could decide if any given scenario is
supported. That may require some reworking of the scenario.

Dr. Leff: So I should be trying to categorize the elements?

Jason: I am concerned that we will have another long discussion and not
be able to move forward.

DG So how do we get closure?

Peter: By surfacing the functional requirements.

Dr. Leff: Perhaps we should add another column to Jason's table. We may
need to work off line.

DG: The only pieces that are not captured are 1. What types of parties
are these, and 2. What types of contracts are we discussing within the
scenario. Those are the only two that I recall...

We should probably defer the proceedings and the ABA an SF discussions
to the next meeting.

Zoran: Any way we can limit our time to 2 hours maximum.

DG: Apologies.

The meeting was adjourned at this point.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]