Subject: TRADE WG Mailing List Archives URL
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 30 Mar 2001 09:37:34 -0500

Hi,

The mailing list archives URL given on the WG Charter Page and in some
drafts is incorrect.  The correct URL is

	    http://lists.eListX.com/archives/ietf-trade
           ^^^^^

I'm working on getting the Charter Page fixed and drafts will be
udated as they are revised...

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)

Date: Wed, 28 Mar 2001 15:23:27 -0500
From: Donald Eastlake 3rd <[email-masked]>
Subject: draft Minutes from 50th IETF
Sender: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]

Hi,

Below are the draft minutes.  Thanks to Walt Houser.

Donald
==================================================================
 Donald Eastlake 3rd  +1 508-634-2066(h)  [email-masked]
 155 Beaver Street    +1 508-261-5434(w)  [email-masked]
 Milford, MA 01757 USA

Internet Open Trading Protocol Working Group (WG) - TRADE
Minutes of meeting in Minneapolis at the 50th IETF Meeting

WEDNESDAY, March 21 at 1300-1500
================================

CHAIR:	Donald E. Eastlake 3rd <[email-masked]> 
REPORTER:  Walter Houser <[email-masked]>
edits: Donald E. Eastlake 3rd.

Agenda Bashing - no change.

Documents Status - Don presented his report, which appear in the
slides that will be submitted to the proceedings.  Three documents
have in working group last call for some time:
draft-ietf-trade-iotp-v1.0-papi-03.txt,
draft-ietf-trade-iotp-v1.0-set-02.txt, and
draft-ietf-trade-drt-requirements-02.txt.  Due to comments during WG
last call, the title Digital Rights has been changed to Voucher in the
drt-requirements draft.  Minor edits for readability have been made in
the papi-03 draft producing papi-04 which is available from
<ftp://ftp.pothole.com/pub/ietf-trade/> and will shortly be posted in
the IETF Internet-Draft directories.  The consensus among those at the
WG meeting was to submit these for publication as Informational RFCs.

Don listed the existing drafts currently under consideration:
draft-ietf-trade-voucher-lang-00.txt,
draft-ietf-trade-ecml2-req-00.txt, draft-ietf-trade-ecml2-spec-00.txt,
draft-ietf-trade-iotp2-req-00.txt.  The ECML Version 2 requirements
document is fairly close to final but the others need work.

Two WG documents are called for that do not yet exist:

1) Secure Channel Credit Debit, a payment method of equivalent
security to HTML forms.  Don suggested this might be accomplished by
light encapsulation of ECML.  There were no objections at the meeting
to this approach.

2) IOTP v2 specification, scheduled for April, no author yet which
makes meeting that milestone pretty unlikely...

Tony Lewis requested that updated milestone dates be posted in the
WG's IETF web page.  Don will look into the Charter change that would
require.

IOTP/ECML Implementation Experience - Don reported that these include
the V1 IOTP Japanese SMILE project.  There is a partial list of
merchant sites at http://www.ecml.org/, but the list needs to be
updated. It notes the IBM wallet and the Microsoft wallet.

ECML V2 Requirements - Is this ready for last call?  Don plans a last
call in a month. V1 was HTML form oriented, whereas v2 is to be XML
oriented.  Comments solicited.

ECML V2 Specification - ISO 8583 fields being added.  Dave Shepherd of
IBM (mailto:[email-masked]) suggested incorporating changes for
Java Commerce messages (JCM). JCM uses lineItems, which do not appear
in ECML v2. We currently don't have a namespace for ECML. V1 has a DTD
but no schema or namespace. Parsons has added fields for v2.
	What syntax do we use to ask for missing data? When asking for
data, how do we indicate whether the request is Optional or mandatory?

XML Voucher: Generic Voucher Language - Ko Fujimura of NTT
(mailto:[email-masked]) presented background on voucher and
current status. Voucher component is not an instance but a definition
of voucher. VC defines the rights (or value) per one unit of the
voucher instance. Ko outlined the processing model (see slides). Ko
plans to publish an API. He is proposing a new trust model based on
the voucher components (see slides). The monetary value properties are
needed to calculating the redemption. His studies suggest that 90
percent of vouchers can be provided using three or four properties:

1. Minimum number of vouchers needed for redemption
2. Merchandise limitation
3. Merchandise value can be specified in as fixed or percentage of
discount. 

An xml:ns is specified. Proposed actions for April include
Internet-Draft on XML voucher and submit Internet-Draft on VTS
(Voucher Trading System) API.  Although much discussion on voucher, no
major issues so far. Ko asked how should we proceed with specifying
the VTS API?

Don noted that our past experience in specifying an API in XML was not
satisfactory. But a Java or C binding is reasonable. As the author
provides the dates, he saw no problem. There were no other comments.

IOTP V2 Requirements - Version 2 is to be a superset of v1 (but not
necessarily backward compatible), dynamic definition of trading
sequences, offer request block, improved problem resolution, handle
payment protocols not tunneled through IOTP, say via TCP.  Optional
items include support for wallet servers, repeated or ongoing in
payment, enhance server to server (timing of submissions to the
payment handler), and the ability to add both fields and attributes to
trading blocks. Not to be included are legal and regulatory issues,
the XML messaging layer, and XML digital signature.  Perhaps a profile
on these standards use with IOTP V2 may in order.

Walt Houser asked which XML messaging layer would be used? Don replied
that was to be decided but he thought ebXML was a bit ahead.  Walt
noted that ebXML uses SOAP rather than BEEP. SOAP is an industry
consortia protocol that competes with the IETF BEEP standard.

Tony Lewis asked if there is anything in the way of the digital
signature becoming a standard?  Don replied that the work of the joint
IETF/W3C XML Digital Signature Work Group is currently a Proposed
Standard in the IETF and a Candidate Recommendation in the W3C.  The
W3C plans to make it a full RECommendation abut the time the IETF
should be advancing it to Draft Standard.  It is unclear when the IETF
will further advance it to Full Internet Standard because this
requires widespread deployment.

Ko asked how would one approach dynamic definition of trading
sequences. Don replied describing one method, which has been partially
specified by Dave Burdett, where the merchant proposes the structure
of the trade along with the prices and currencies, etc.

Schedule of Future Actions/Meetings -

1) Authors are needed for SCCD and IOTP v2 specification

2) The WG will meet in London in early August and until then continue
work on the mailing list.

The WG meeting adjourned at 14:22

Date: Wed, 28 Mar 2001 12:37:55 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: Comment on draft-ietf-trade-iotp2-req-00.txt
To: Walt Houser <[email-masked]>
Cc: [email-masked]

Hi,

From:  Walt Houser <[email-masked]>
Date:  Wed, 21 Mar 2001 10:18:37 -0800 (PST)
To:  [email-masked], Walter Houser <[email-masked]>
Message-id:  <[email-masked]>

>The ID states:
>
>   The following are out of scope for IOTP version 2:
>
>   1. Legal or regulatory issues surrounding the
>      implementation of the
>      protocol or information systems using it.
>
>   2. Design of an XML Messaging Layer.
>
>wh: Should the ID point to BXXP? SOAP? XP?

It could but I don't think it is necessary for the requirmeents draft
to specify the particular Messaging to be used.  It is also not clear
to me how soon this will settle out and whether people will gravitate
towards one method or a few...making it hard to give a specific
pointer.

>   3. Design of XML Digitial Signatures.
>
>wh: Should the ID point to XMLDS?
>http://www.w3.org/TR/xmldsig-core/ 

Similarly, I don't think it has to.  But in this case, the standard
has been adopted and the ID might as well give a reference.  Since
this is an IETF effort, it should point to the RFC which should be out
any day now...

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd                    [email-masked]
 155 Beaver Streeet                         [email-masked]
 Milford, MA 01757 USA     +1 508-634-2066(h)   +1 508-261-5434(w)

Date: Mon, 26 Mar 2001 18:25:52 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Comments on Attributes/Elements
To: Walter Houser <[email-masked]>
Cc: IETF Trade <[email-masked]>

Hi Walt,

There are a number of viewpoints regarding this question as you see:

  http://xml.coverpages.org/elementsAndAttrs.html

I have no strong preference, but I prefer attribute to element for 
describing short contents as we do in IOTP or ECML, e.g., BrandName, 
ProtocolName, WalletID, ...

Walt Houser wrote:
> 
> Why use attributes
> 
>      <Provider Name="Voucher Wallet 2001">
>        <vts:KeyInfo>...</vts:KeyInfo>
>      </Provider>
>      <Issuer Name="Alice Book Center, Ltd.">
>        <vts:KeyInfo>...</vts:KeyInfo>
>      </Issuer>
> 
> instead of elements?
> 
>      <Provider>
>      <Name>Voucher Wallet 2001</Name>
>        <vts:KeyInfo>...</vts:KeyInfo>
>      </Provider>
>      <Issuer>
>      <Name>Alice Book Center, Ltd.</Name>
>        <vts:KeyInfo>...</vts:KeyInfo>
>      </Issuer>

Regards,

Ko
----------------------------------------------------------
Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-2241
Email: [email-masked]

Date: Wed, 21 Mar 2001 11:05:58 -0800 (PST)
From: Walt Houser <[email-masked]>
Subject: Comments on
To: IETF Trade <[email-masked]>
Cc: Walter Houser <[email-masked]>

Why use attributes 

     <Provider Name="Voucher Wallet 2001">
       <vts:KeyInfo>...</vts:KeyInfo>
     </Provider>
     <Issuer Name="Alice Book Center, Ltd.">
       <vts:KeyInfo>...</vts:KeyInfo>
     </Issuer>

instead of elements?

     <Provider>
     <Name>Voucher Wallet 2001</Name>
       <vts:KeyInfo>...</vts:KeyInfo>
     </Provider>
     <Issuer>
     <Name>Alice Book Center, Ltd.</Name>
       <vts:KeyInfo>...</vts:KeyInfo>
     </Issuer>

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Date: Wed, 21 Mar 2001 10:18:37 -0800 (PST)
From: Walt Houser <[email-masked]>
Subject: Comment on draft-ietf-trade-iotp2-req-00.txt
To: [email-masked], Walter Houser <[email-masked]>

The ID states:

   The following are out of scope for IOTP version 2:

   1. Legal or regulatory issues surrounding the
      implementation of the
      protocol or information systems using it.

   2. Design of an XML Messaging Layer.

wh: Should the ID point to BXXP? SOAP? XP?

   3. Design of XML Digitial Signatures.

wh: Should the ID point to XMLDS?
http://www.w3.org/TR/xmldsig-core/ 

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Date: Wed, 21 Mar 2001 13:07:33 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Minor edit of IOTP Payment API Draft
To: [email-masked]
Cc: [email-masked], [email-masked]

A version of the Payment API draft with minor editing changes is now
available at
<ftp://ftp.pothole.com/pub/ietf-trade/draft-ietf-trade-iotp-v1.0-papi-04.txt>.
This will probably be in the Internet-Draft directories next week.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)

Date: Wed, 14 Mar 2001 14:58:03 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Draft Agenda for Minneaplis
To: [email-masked]
Cc: [email-masked]

Here is a draft agenda for the working group meeting at the 50th IETF
meetingin Minneapolis next week.  Comments welcome.

TRADE WG Draft Agenda (WEDNESDAY, March 21, 2001)

13:00	Agenday Bashing
13:10	Documents Status
13:20	IOTP/ECML Implementation Experience
13:35	ECML V2 Requirements
13:50	ECML V2 Specification
14:05	XML Voucher: Generic Voucher Language
14:35   IOTP V2 Requirements
14:50	Schedule Future Actions/Meetings
15:00	End

=====================================================================
  Donald E. Eastlake 3rd                      [email-masked]
  155 Beaver Street                                +1 508-634-2066(h)
  Milford, MA 01757 USA                            +1 508-261-5434(w)

Date: Wed, 14 Mar 2001 12:19:51 -0400
From: Ian Grigg <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
Sender: [email-masked]
To: Ko Fujimura <[email-masked]>
Cc: Rachel Willmer <[email-masked]>, [email-masked], [email-masked]
Reply-to: [email-masked]

Ko Fujimura wrote:
...
> > IMHO, there is no useful meaning to a Ricardian contract
> > "conforming" to a particular layout such as that described
> > for bonds.  Every bond is different, and there is no good
> > reason to make them all the same.  What will happen over
> > time is that new bonds will introduce new tags, and software
> > vendors will be encouraged to interpret these extra fields
> > according to their usefulness.
> 
> I agree. It is impossible to develop a specification that covers all types of
> vouchers in the world. I think that the goal of XML voucher is to cover 90%(?)
> of vouchers without introducing implementation difficulties.

OK.  Our goal with Ricardian Contracts is more adventurous,
to cover 100% of financial instruments :)  So far we've not
struck a case we can't say something about, although I admit
that futures are a bit tricky in Ricardo -- it's not obvious
how to deliver a tonne of pork bellies over the net.

As we are trying to cover everything, we do have sections
in there for different styles of instruments, and the format
allows the addition of others.  There are certain limitations
that may mitigate against some instruments, for example, the
format assumes that there is one central signatory, which is not
always the case.  But, it is close enough to the existing set
of contracts we work with, so it is put in the "future work"
basket of tasks.

[ Vouchers in the sense of tickets and loyalty we've never
really looked at closely... ]

> In the current voucher draft, <Title> is introduced for describing the name of the
> voucher (incl. currency).

<Title> is fine.  There is a need for several versions of the title,
there is at least a shortname and a full, legal title.  With currencies
there are often ISO TLAs and with shares there are often "symbols".

The shortname and the symbol are important variables for the program
to read.

You could do something like:

<Title shortname="Systemics" symbol="SYX">
  Systemics Incorporated
</Title>

> I'm not sure whether <type> is really needed, since other standards, e.g., IOTP, ECML,
> FTSC, X9.59, ..., does not has the property, and there is no modern currency that are
> not decimal.

The question revolves around whether you think that this field
forms part of the contract.  In my view, the type is a part of
the contract.

Other standards simply ignore the contract, and this is one
reason why they fail to grow into new areas.  For example, you'd
be hard pressed to find another standard that could differentiate
between a dollar issued by the Federal Reserve and a dollar issued
in the Euro markets - they pretty all much assume that the ISO has
it right and using the TLA "USD" will cover it.

You are right that there is no modern currency that is non-decimal,
and I can't even think of a bond or share or other instrument that
might be non-decimal.  So probably what I should do is make the
default for "type" be "decimal" and leave the question of other
conventions for whoever can find one.

> I understand that you introduced <decimal_power> to give the mapping information
> between the amount managed by the account (or SOX protocol) and the unit of the
> currency displayed. This is good idea since underlying system such as VTS does not
> have to care about the unit. Using this mapping information, a wallet system can
> transform it in a human readable form.

Yes, that's right.  The nature of the "cents" in any currency is
a decided part of the contract, but software works in cents whilst
humans work in dollars.  How this difficulty is resolved is very
important to a payment system.

> In the current voucher draft, I introduced <Value ratio="nnnn"/> syntax for similar
> purpose. Using this syntax, Ivan's dollar can be defined as follows:
> 
> <Voucher>
>   ...
>   <Promise>
>     <Title>Ivan's dollars</Title>
>     <Description>
>       Ivan's dollars are ...
>     </Description>
>     ...
>     <Value ratio="0.01" currency="USD" amount="1"/>
>     <Conditions>Only valid in Ivan's shops</Conditions>
>     ...
>   </Promise>
>   ...
> </Voucher>
> 
> I found currency_factor parameter in the Ricardian Contract. I think it is the same
> as the ratio attribute above. By the way, I think that either currency_factor or
> currency_decimal_power is enough for defining the mapping, am I right?

That's correct.  WebFunds has a routine that searches for each of them,
and uses the best available information.

> If so, why
> you choose currency_decimal_power? I think currency_factor is more flexible.

Currency_factor is in fact what we originally worked with, as it is
on the surface more flexible;  we can do something like .005 easily.

It turned out to be more of a nuisance than a feature.  Just as all
currencies are decimal, they are also all powers of ten.  By that, I
mean there was no *useful* scenario where we came across that required
a 200 cents in the dollar breakup.

[ I.e., in the beloved guilder economy, there are only 5c coins, they
abandoned the 1c a long time ago.  So, yes, if we wanted to issue
Ricardian guilders, we might want to set the factor to 0.05.  However,
it's all a matter of convenience, and there is more sense in setting
it to 0.01 and running with single cents as the software solves the
cost factor that caused the Dutch mint to drop the 1c coin. ]

And, the reason that sparked the change to decimal_power was that
programming with factors was hard.  Whilst accurate in the contract,
we had continual problems where the program code would trip up on
the fixed point calculations.  So, it became easier to set the power
as an integer 2, -2, whatever, and then write some support code that
produced the strings when necessary.  More code, but easier to control.

> Sorry for asking a lot. But, your experiences are really helpful for developping the
> specification.

No problem - as I say I intend to use your Voucher as the starting
point for the Ricardian conversion to XML.  The more work we get
done now, the easier it will be later :)

> I didn't introduce <fraction> in the above. Because, "$0.01" seems to be ok instead of
> "1c" in many cases, and the translation is quite easy in XML using the style sheet.

OK.  Another thing to be aware of is what it is you are defining.
In Ricardian Contracts, they define the "unit of contract" which
is always the unit that the software deals in.  I.e., cent or
milligram.  Then, the power/fraction/factor is used to define an
alternate representation for humans, called the "unit of account."

Getting this right is important - it needs to be part of the standard,
as software needs to agree and account for each and every cent.  Most
payment systems define both the unit of account and the unit of contract
as being equally important, and thus get themselves into all sorts of
knots trying to work out how to deal with them.

Also, bear in mind that I've moved the power into the previous section
so that *all* contracts are now subject to the units capability.  This
is because we've found that issuing shares or bonds with units of account
and distinct units of contract actually makes sense.  That is, millishares
is a "good idea" under some circumstances.

[ The best example of this is the shares in Warren Buffet's company,
Berkshire-Hathaway, which he deliberately never split as he wanted to
only keep large, important shareholders.  When they got to be worth 5
figures in dollars, even the papers had to stop quoting the share
price because the price columns only supported 4 figures.  Now, we
of course could break his game by issuing what I call Bufflets,
being microshares.  The unit of account would be one BH share, and
the unit of contract could be a millionth of that. ]
 
> > (for example ...)  One thing I'm unsure of is the appropriate form,
> > should it be tags everwhere or fields?  E.g., would the following
> > be more appropriate:
> >
> >  ...
> >  <currency name="ivan's dollars" type="decimal" power=2 fraction="c">
> >   Ivan's dollars are denominated in dollar units, with a fractional
> >   unit of contract of a cent.
> >  </currency>
> 
> That's fine. But I'm not sure whether the meaning should be written in natural
> language for monetary value, since its semantics is strictly defined using the
> attributes. But, non monetary value this syntax might be more appropriate...

Correct, this is one of the legal conundrums of a digital contract, what
happens when a defined field disagrees with a comment?

In my view, the fields dominate and the comments should be written to
explain the fields.  That's what I tell all the issuers, and in time I'd
hope that would become established as a custom (assuming my view is
valuable, that is).

What happens when a comment disagrees with a field is a gray area, and
I'm deliberately leaving this as a gray area.  That is, a judge would have
to rule.  So, an issuer would write a contract, and check the fields and
comments match.  And if they don't, then there are consequences.  But the
nature of those consequences are, IMHO, more properly determined in the
courts than in the technology.

[ For similar reasons, I will probably deliberately ban any "critical"
bit as exists in the FSML spec.  The effect of that is a legal nightmare,
only plausible in FSML because they are not really doing contracts, just
checks/cheques. ]

> <Voucher>
>   ...
>   <Promise>
>     <Title>Ivan's gold voucher (1mg)</Title>
>     <Description>
>       This voucher can be exchanged for 1mg of gold.
>     </Description>
>     ...
>     <Merchandise ratio="0.001" unit="g" amount="1">  [or ratio="1" unit="mg"]

Right, so here you need to make clear what both the minor unit
is and what the major unit is.  You will need a name for both of
them, and of course the ratio between them.  Something like:

<... ratio="0.001" major_unit="g" minor_unit="mg">

where I've used major and minor rather than my terms "unit of account"
and "unit of contract" to avoid assuming your intentions :)

>       Ivan's gold vouchers are denominated in gram of gold, with a fractional
>       unit of a milligram.
>     </Merchandise>
>     <Conditions>...</Conditions>
>     ...
>   </Promise>
>   ...
> </Voucher>
> 
> By the way, I'm not sure gold is currency or merchandise :-)

You may not be aware of the emerging gold economy, originated by the
e-gold company, with something like a tonne of gold in issuance as a
currency.  Digital gold is mostly a currency, sometimes a financial
instrument, but it is unlikely to make much impact as merchandise,
as digital gold doesn't have the allure and fashionability that
physical gold jewellry has.

-- 
iang

Date: Wed, 14 Mar 2001 20:48:43 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: [email-masked]
Cc: Rachel Willmer <[email-masked]>, [email-masked], [email-masked], [email-masked]

Ian Grigg wrote:
> ...
> > I think some of properties of the contract do not have to be interpreted
> > by the program and they are defined only for clarifying its legal meaning.
> > In case of bond, for example, bond_face, bond_currency, and
> > bond_maturity_date are needed to be processed especially when it is
> > redeemed. But, bond_issue_date and bond_total_issue_number seem to be
> > defined only for clarifying its legal meaning, am I right?
> 
> That's correct - the intention is to let a bond
> writer put in the fields he wants, and guide the important
> fields with conventions.  Obviously, things like face and
> maturity are needed so that calculations can be done.  The
> addition of the issue_date, etc, is simply there to complete
> the full set of data, not because a program can use them.
> 

Thank you very much for information. It's really helpful for considering the properties
of value (or voucher). 

> IMHO, there is no useful meaning to a Ricardian contract
> "conforming" to a particular layout such as that described
> for bonds.  Every bond is different, and there is no good
> reason to make them all the same.  What will happen over
> time is that new bonds will introduce new tags, and software
> vendors will be encouraged to interpret these extra fields
> according to their usefulness.

I agree. It is impossible to develop a specification that covers all types of 
vouchers in the world. I think that the goal of XML voucher is to cover 90%(?)
of vouchers without introducing implementation difficulties.

> 
> (Another thing to bear in mind is that the bonds area, whilst
> the original genesis of the Ricardo project, has not been
> used since the early days.  We've done most of the last 3
> years doing commodity currencies (precious metals) and are
> currently experimenting with shares and national currencies.)
> 
> > I think that we do not have to introduce specific tags for these
> > properties which are not interpreted by the software, since it is
> > sufficient to write them in a plain text in "one" XML element such as
> > <Contract>...</Contract>. I think it can be used as a criteria whether we
> > introduce as an element in XML voucher or not.
> > How do you think this approach?
> 
> Initially that would be fine - experience would guide us as to
> how to develop the inner parts.
> 
> One thing that happened with currency contracts that I didn't
> predict was that a currency issuer added a complete section
> called [conditions] and a lot of fields like conditions_backing,
> conditions_reserves, conditions_audit...  which all specified
> the terms of the contract in those particular areas.

It's good suggestion. I think we should introduce the <Conditions> element for 
that purpose.

> 
> Likewise, a new contract that is being worked on by an issuer
> has added a complete [definitions] section at the very beginning.
> If we were to translate his contract to an XML format, it would
> look like:
> 
> <contract>
>  <definitions>
>   <dollars>
>    [ivan's] dollars are ...
>   </dollars>
>   ...
>  </definitions>

In the current voucher draft, there is a <Description> element. I think the purpose
of <definitions> seems to be similar...

> 
>  <entity>
>   <shortname>...</shortname>
>  </entity>
> 
>  <issue>
>   ...
>  </issue>
> 
>  <currency>
>   <name>[ivan's] dollars</name>
>   <tla>USD</tla>
>   <type>decimal</type>
>   <decimal_power>2</decimal_power>
>   <fraction>c</fraction>
>  </currency>
>  ...
> </contract>
> 

In the current voucher draft, <Title> is introduced for describing the name of the
voucher (incl. currency).

I'm not sure whether <type> is really needed, since other standards, e.g., IOTP, ECML,
FTSC, X9.59, ..., does not has the property, and there is no modern currency that are 
not decimal.

I understand that you introduced <decimal_power> to give the mapping information 
between the amount managed by the account (or SOX protocol) and the unit of the 
currency displayed. This is good idea since underlying system such as VTS does not 
have to care about the unit. Using this mapping information, a wallet system can 
transform it in a human readable form.

In the current voucher draft, I introduced <Value ratio="nnnn"/> syntax for similar
purpose. Using this syntax, Ivan's dollar can be defined as follows:

<Voucher>
  ...
  <Promise>
    <Title>Ivan's dollars</Title>
    <Description>
      Ivan's dollars are ...
    </Description>
    ...
    <Value ratio="0.01" currency="USD" amount="1"/>
    <Conditions>Only valid in Ivan's shops</Conditions>
    ...
  </Promise>
  ...
</Voucher>

I found currency_factor parameter in the Ricardian Contract. I think it is the same 
as the ratio attribute above. By the way, I think that either currency_factor or 
currency_decimal_power is enough for defining the mapping, am I right? If so, why 
you choose currency_decimal_power? I think currency_factor is more flexible.
Sorry for asking a lot. But, your experiences are really helpful for developping the
specification.

I didn't introduce <fraction> in the above. Because, "$0.01" seems to be ok instead of 
"1c" in many cases, and the translation is quite easy in XML using the style sheet. 

> (for example ...)  One thing I'm unsure of is the appropriate form,
> should it be tags everwhere or fields?  E.g., would the following
> be more appropriate:
> 
>  ...
>  <currency name="ivan's dollars" type="decimal" power=2 fraction="c">
>   Ivan's dollars are denominated in dollar units, with a fractional
>   unit of contract of a cent.
>  </currency>

That's fine. But I'm not sure whether the meaning should be written in natural 
language for monetary value, since its semantics is strictly defined using the 
attributes. But, non monetary value this syntax might be more appropriate...

<Voucher>
  ...
  <Promise>
    <Title>Ivan's gold voucher (1mg)</Title>
    <Description>
      This voucher can be exchanged for 1mg of gold.
    </Description>
    ...
    <Merchandise ratio="0.001" unit="g" amount="1">  [or ratio="1" unit="mg"]
      Ivan's gold vouchers are denominated in gram of gold, with a fractional
      unit of a milligram.
    </Merchandise>
    <Conditions>...</Conditions>
    ...
  </Promise>
  ...
</Voucher>

By the way, I'm not sure gold is currency or merchandise :-)

Thank you!!

Ko

Date: Mon, 12 Mar 2001 18:18:45 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: [email-masked]
Cc: [email-masked], Rachel Willmer <[email-masked]>, [email-masked], [email-masked], [email-masked]

Hi Lynn,

Thank you very much for providing us a lot of X9.59 information.

I understand that the encoding rules of the spec will be helpful if XML Voucher 
have to define XML-encoding rules of a signed object...

But, the digital signature (or signed object) is used only in the delivery of 
Voucher Component or within the VTS-specific protocols that rewrite the ownership
of a voucher in the current XML Voucher processing model. In either cases, the 
XML-encoding rules of a signed object is outside scope of the XML Voucher 
specification (e.g., Encoding rules defined in XMLDSIG is another candidate).
This language design is one of major issues to be discussed in the next IETF 
meeting, though.

Thanks,

Ko
[email-masked] wrote:
> 
> there were/are two parts of FSML ....
> 
> 1) deterministic encoding rules for tagged grammers so that the signed object
> and the object having signature being verified will work in circumstances where
> the intermediate message have have totally mangled the original signed object.
> 
> 2) echeck
> 
> on the other hand, X9.59 standard was targeted at all account-based electronic
> payments; credit, debit, ATM, echeck, ACH, wire-transfers, internet,
> point-of-sale, wireless, etc.
> 
> The X9.59 standard calls for ASN.1 encoding.
> 
> A mapping of X9.59 to ISO8583 shows the original object being signed and then
> the fields from the original signed object being transmitted as ISO8583 fields
> (not in the format of the originally signed object) and then the originally
> signed object is reconstructed at the relying party and the signature verified.
> 
> An X9.59 object using  XML-ecoding rules could be implemented. However, in the
> case of the mapping example of X9.59 to ISO8583, the reconstruction of the
> signed object at the relying party has to be deterministic. As far as I know,
> FSML was the original tagged definition that specified deterministic encoding
> rules ... that would allow tagged-encoded objects to be reconstructed in a
> deterministic manner (therefor the FSML reference; not because of the echeck
> specification but because of its specifying deterministic encoding rules for
> tagged fields).

Date: Sat, 10 Mar 2001 10:26:38 -0800
From: Todd Boyle <[email-masked]>
Subject: RE: implementations of "XML Voucher: Generic Voucher Language" ?
To: [email-masked], Ko Fujimura <[email-masked]>
Cc: Rachel Willmer <[email-masked]>, [email-masked], [email-masked]
Reply-to: [email-masked]
Importance: Normal

I would like to point out the unmet need in the webledger space,
for any practical or standard technique by which a subscriber
might issue securitized payables obligations.

A webledger is a general accounting platform that runs in a
browser, and is only one of a large category of web apps in
which subscribers buy stuff or form accounts payable liabilities
of some sort.

At present, the banking industry (and a ravenous horde of billing
and payments solutions hardwired to the banking industry) are
pushing all kinds of **payment** solutions, i.e. crap that makes
you push every settlement thru a bank someplace.

There is considerable awareness in the webledger communities
that intercompany journal entries can be used to perform very
simple, well-understood balance sheet transfers to reassign
payables and receivables, from one party to another in your
ledger i.e. zero out all your payables or receivables and
send the information to a settlement agent.  This is obviously
an appealing idea to most small businesses if issues can be
put to rest regarding cost, trust, confidentiality and so forth.

Your role, as cryptologist is to show the webledger community
your least-common-denominator, absolutely common-sense software
algorithm and workflow for securitizing payables.  You need an
object that accepts rows of accounts payable ledger in some
standard such as OMG GL or emerging OMG AR/AP schemas, and
signs them somehow to be nonrepudiable by the issuer and prevents
double-spending.

The vision is that a recipient such as a settlement agent, will
receive a bundle of signed payables from a particular party,
such as MyWebledger:Subscriber234234 and there would be some
kind of protocol to contact MyWebledger over the intenret,
making MyWebledger, in effect, the host to prevent doublespending.
After a bit of round-trip verifying, the settlement agent would
have some measurable improvement in confidenc that the payable
was bonafide and hasn't been a complete fraud.   Yeah I know,
crackers might still find a hole.  Well, that's ok. This is
way better than sendnig GL rows in the clear over a VPN connection
or something-- all the solutions are nonstandard, today.

Another deliverable from this project might be that the
securitized payables message optionally, is encrypted to
be readable only by the intended addressee.  THe preferred
application however, is a free-for-all in which reputable
small businesses issue their own money and we all trade using
that money.  Obviously the large corps will collude to not
use this system but small businesses operate under different
incentives and cost pressures.

Finally, the receiver's object would extract, from the securitized
payables, the sets of accounts payable rows in ledger format
so that they can be managed and processed by the AR/AP system
of the receiver.

TOdd

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Ian Grigg
Sent: Friday, March 09, 2001 6:44 PM
To: Ko Fujimura
Cc: Rachel Willmer; [email-masked]; [email-masked]
Subject: Re: implementations of "XML Voucher: Generic Voucher Language"
?

<snip>
> By the way, I'm studying how to write your bond and currency defined
> in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
> in XML voucher.

Great!  Let me know when you're ready to issue :)

> I think some of properties of the contract do not have to be interpreted
> by the program and they are defined only for clarifying its legal meaning.
> In case of bond, for example, bond_face, bond_currency, and
> bond_maturity_date are needed to be processed especially when it is
> redeemed. But, bond_issue_date and bond_total_issue_number seem to be
> defined only for clarifying its legal meaning, am I right?

That's correct - the intention is to let a bond
writer put in the fields he wants, and guide the important
fields with conventions.  Obviously, things like face and
maturity are needed so that calculations can be done.  The
addition of the issue_date, etc, is simply there to complete
the full set of data, not because a program can use them.

IMHO, there is no useful meaning to a Ricardian contract
"conforming" to a particular layout such as that described
for bonds.  Every bond is different, and there is no good
reason to make them all the same.  What will happen over
time is that new bonds will introduce new tags, and software
vendors will be encouraged to interpret these extra fields
according to their usefulness.

(Another thing to bear in mind is that the bonds area, whilst
the original genesis of the Ricardo project, has not been
used since the early days.  We've done most of the last 3
years doing commodity currencies (precious metals) and are
currently experimenting with shares and national currencies.)

> I think that we do not have to introduce specific tags for these
> properties which are not interpreted by the software, since it is
> sufficient to write them in a plain text in "one" XML element such as
> <Contract>...</Contract>. I think it can be used as a criteria whether we
> introduce as an element in XML voucher or not.
> How do you think this approach?

Initially that would be fine - experience would guide us as to
how to develop the inner parts.

One thing that happened with currency contracts that I didn't
predict was that a currency issuer added a complete section
called [conditions] and a lot of fields like conditions_backing,
conditions_reserves, conditions_audit...  which all specified
the terms of the contract in those particular areas.

Likewise, a new contract that is being worked on by an issuer
has added a complete [definitions] section at the very beginning.
If we were to translate his contract to an XML format, it would
look like:

<contract>
 <definitions>
  <dollars>
   [ivan's] dollars are ...
  </dollars>
  ...
 </definitions>

 <entity>
  <shortname>...</shortname>
 </entity>

 <issue>
  ...
 </issue>

 <currency>
  <name>[ivan's] dollars</name>
  <tla>USD</tla>
  <type>decimal</type>
  <decimal_power>2</decimal_power>
  <fraction>c</fraction>
 </currency>
 ...
</contract>

(for example ...)  One thing I'm unsure of is the appropriate form,
should it be tags everwhere or fields?  E.g., would the following
be more appropriate:

 ...
 <currency name="ivan's dollars" type="decimal" power=2 fraction="c">
  Ivan's dollars are denominated in dollar units, with a fractional
  unit of contract of a cent.
 </currency>

--
iang

Date: Fri, 09 Mar 2001 22:44:28 -0400
From: Ian Grigg <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
Sender: [email-masked]
To: Ko Fujimura <[email-masked]>
Cc: Rachel Willmer <[email-masked]>, [email-masked], [email-masked]
Reply-to: [email-masked]

<snip>
> By the way, I'm studying how to write your bond and currency defined
> in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
> in XML voucher.

Great!  Let me know when you're ready to issue :)

> I think some of properties of the contract do not have to be interpreted
> by the program and they are defined only for clarifying its legal meaning.
> In case of bond, for example, bond_face, bond_currency, and
> bond_maturity_date are needed to be processed especially when it is
> redeemed. But, bond_issue_date and bond_total_issue_number seem to be
> defined only for clarifying its legal meaning, am I right?

That's correct - the intention is to let a bond
writer put in the fields he wants, and guide the important
fields with conventions.  Obviously, things like face and
maturity are needed so that calculations can be done.  The
addition of the issue_date, etc, is simply there to complete
the full set of data, not because a program can use them.

IMHO, there is no useful meaning to a Ricardian contract
"conforming" to a particular layout such as that described
for bonds.  Every bond is different, and there is no good
reason to make them all the same.  What will happen over
time is that new bonds will introduce new tags, and software
vendors will be encouraged to interpret these extra fields
according to their usefulness.

(Another thing to bear in mind is that the bonds area, whilst
the original genesis of the Ricardo project, has not been
used since the early days.  We've done most of the last 3
years doing commodity currencies (precious metals) and are
currently experimenting with shares and national currencies.)

> I think that we do not have to introduce specific tags for these
> properties which are not interpreted by the software, since it is
> sufficient to write them in a plain text in "one" XML element such as
> <Contract>...</Contract>. I think it can be used as a criteria whether we
> introduce as an element in XML voucher or not.
> How do you think this approach?

Initially that would be fine - experience would guide us as to
how to develop the inner parts.

One thing that happened with currency contracts that I didn't
predict was that a currency issuer added a complete section
called [conditions] and a lot of fields like conditions_backing,
conditions_reserves, conditions_audit...  which all specified
the terms of the contract in those particular areas.

Likewise, a new contract that is being worked on by an issuer
has added a complete [definitions] section at the very beginning.
If we were to translate his contract to an XML format, it would
look like:

<contract>
 <definitions>
  <dollars>
   [ivan's] dollars are ...
  </dollars>
  ...
 </definitions>

 <entity>
  <shortname>...</shortname>
 </entity>

 <issue>
  ...
 </issue>

 <currency>
  <name>[ivan's] dollars</name>
  <tla>USD</tla>
  <type>decimal</type>
  <decimal_power>2</decimal_power>
  <fraction>c</fraction>
 </currency>
 ...
</contract>

(for example ...)  One thing I'm unsure of is the appropriate form,
should it be tags everwhere or fields?  E.g., would the following
be more appropriate:

 ...
 <currency name="ivan's dollars" type="decimal" power=2 fraction="c">
  Ivan's dollars are denominated in dollar units, with a fractional
  unit of contract of a cent.
 </currency>

-- 
iang

Date: Fri, 09 Mar 2001 14:09:05 -0800
From: [email-masked]
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: Ko Fujimura <[email-masked]>
Cc: [email-masked], Rachel Willmer <[email-masked]>, [email-masked], [email-masked], [email-masked]

there were/are two parts of FSML ....

1) deterministic encoding rules for tagged grammers so that the signed object
and the object having signature being verified will work in circumstances where
the intermediate message have have totally mangled the original signed object.

2) echeck

on the other hand, X9.59 standard was targeted at all account-based electronic
payments; credit, debit, ATM, echeck, ACH, wire-transfers, internet,
point-of-sale, wireless, etc.

The X9.59 standard calls for ASN.1 encoding.

A mapping of X9.59 to ISO8583 shows the original object being signed and then
the fields from the original signed object being transmitted as ISO8583 fields
(not in the format of the originally signed object) and then the originally
signed object is reconstructed at the relying party and the signature verified.

An X9.59 object using  XML-ecoding rules could be implemented. However, in the
case of the mapping example of X9.59 to ISO8583, the reconstruction of the
signed object at the relying party has to be deterministic. As far as I know,
FSML was the original tagged definition that specified deterministic encoding
rules ... that would allow tagged-encoded objects to be reconstructed in a
deterministic manner (therefor the FSML reference; not because of the echeck
specification but because of its specifying deterministic encoding rules for
tagged fields).

X9 financial standards body web site:
http://www.x9.org/

ISO (international) financial standards body web site (US is the chair):
http://www.tc68.org/

misc. X9.59 standard description and discussions for all account-based
electronic payments (credit, debit, ATM, echeck, ACH, wire-transfers, internet,
point-of-sale, wireless, etc)
http://www.garlic.com~lynn/

description of the X9.59 standard example mapping to ISO8583
http://www.garlic.com/~lynn/8583flow.htm

X9.59 standard at the ANSI X9 online standards publication store:
http://webstore.ansi.org/ansidocstore/product.asp?sku=DSTU+X9%2E59%2D2000

Ko Fujimura <[email-masked]> on 03/09/2001 05:17:48 AM

To:   [email-masked]
cc:   Lynn Wheeler/CA/FDMS/FDC@FDC, Rachel Willmer <[email-masked]>,
      [email-masked], [email-masked]
Subject:  Re: implementations of "XML Voucher: Generic Voucher Language" ?

Thank you for your advice. But, the FSML v1.5 spec also seems to be
oriented to check processing.

By the way, I'm studying how to write your bond and currency defined
in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
in XML voucher.

I think some of properties of the contract do not have to be interpreted
by the program and they are defined only for clarifying its legal meaning.
In case of bond, for example, bond_face, bond_currency, and
bond_maturity_date are needed to be processed especially when it is
redeemed. But, bond_issue_date and bond_total_issue_number seem to be
defined only for clarifying its legal meaning, am I right?

I think that we do not have to introduce specific tags for these
properties which are not interpreted by the software, since it is
sufficient to write them in a plain text in "one" XML element such as
<Contract>...</Contract>. I think it can be used as a criteria whether we
introduce as an element in XML voucher or not.
How do you think this approach?

Regards,

Ko

Date: Fri, 09 Mar 2001 13:44:44 -0800
From: [email-masked]
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: Ko Fujimura <[email-masked]>
Cc: [email-masked], Rachel Willmer <[email-masked]>, [email-masked], [email-masked], [email-masked]

there were/are two parts of FSML ....

1) deterministic encoding rules for tagged grammers so that the signed object
and the object having signature being verified will work in circumstances where
the intermediate message have have totally mangled the original signed object.

2) echeck

on the other hand, X9.59 standard was targeted at all account-based electronic
payments; credit, debit, ATM, echeck, ACH, wire-transfers, internet,
point-of-sale, wireless, etc.

The X9.59 standard calls for ASN.1 encoding.

A mapping of X9.59 to ISO8583 shows the original object being signed and then
the fields from the original signed object being transmitted as ISO8583 fields
(not in the format of the originally signed object) and then the originally
signed object is reconstructed at the relying party and the signature verified.

An X9.59 object using  XML-ecoding rules could be implemented. However, in the
case of the mapping example of X9.59 to ISO8583, the reconstruction of the
signed object at the relying party has to be deterministic. As far as I know,
FSML was the original tagged definition that specified deterministic encoding
rules ... that would allow tagged-encoded objects to be reconstructed in a
deterministic manner (therefor the FSML reference; not because of the echeck
specification but because of its specifying deterministic encoding rules for
tagged fields).

X9 financial standards body web site:
http://www.x9.org/

ISO (international) financial standards body web site (US is the chair):
http://www.tc68.org/

misc. X9.59 standard description and discussions for all account-based
electronic payments (credit, debit, ATM, echeck, ACH, wire-transfers, internet,
point-of-sale, wireless, etc)
http://www.garlic.com~lynn/

description of the X9.59 standard example mapping to ISO8583
http://www.garlic.com/~lynn/8583flow.htm

X9.59 standard at the ANSI X9 online standards publication store:
http://webstore.ansi.org/ansidocstore/product.asp?sku=DSTU+X9%2E59%2D2000

Ko Fujimura <[email-masked]> on 03/09/2001 05:17:48 AM

To:   [email-masked]
cc:   Lynn Wheeler/CA/FDMS/FDC@FDC, Rachel Willmer <[email-masked]>,
      [email-masked], [email-masked]
Subject:  Re: implementations of "XML Voucher: Generic Voucher Language" ?

Thank you for your advice. But, the FSML v1.5 spec also seems to be
oriented to check processing.

By the way, I'm studying how to write your bond and currency defined
in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
in XML voucher.

I think some of properties of the contract do not have to be interpreted
by the program and they are defined only for clarifying its legal meaning.
In case of bond, for example, bond_face, bond_currency, and
bond_maturity_date are needed to be processed especially when it is
redeemed. But, bond_issue_date and bond_total_issue_number seem to be
defined only for clarifying its legal meaning, am I right?

I think that we do not have to introduce specific tags for these
properties which are not interpreted by the software, since it is
sufficient to write them in a plain text in "one" XML element such as
<Contract>...</Contract>. I think it can be used as a criteria whether we
introduce as an element in XML voucher or not.
How do you think this approach?

Regards,

Ko

Date: Fri, 09 Mar 2001 09:15:00 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: IOTPV2: XML messaging
To: Ko Fujimura <[email-masked]>
Cc: [email-masked]

I'd like to know also.  :-) I think ebXML is the most likely candidate
right now.  The working group consensus has consistently been in favor
of picking a messaging protocol specified elsewhere rather than
rolling our own.  Hopefully the timing will work out so that we can
pick what will become the dominant messaging protocol...

Thanks,
Donald

From:  Ko Fujimura <[email-masked]>
Date:  Fri, 09 Mar 2001 18:02:13 +0900
To:  [email-masked]
Message-id:  <[email-masked]>

>In <http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp2-req-00.txt>:
>
>> INTERNET-DRAFT            IOTP v2 Requirements             February 2001
>> 
>> 
>> 1. Introduction
>> 
>>    Verion 2 of the Internet Open Trading Protocol (IOTP) will extend the
>>    interoperable framework for Internet commerce capabilities of Version
>>    1 [RFC 2801] as described in Section 3 below.  In addition, it will
>>    replace the ad hoc XML messaging and digitial signature [RFC 2802]
>>    parts of IOTP v1 with standards based mechanisms.
>
>Which XML messaging protocols will be used for replacing current XML messaging?
>Do you assume that ebXML TR/P for underlying protocol of IOTP version 2?
>I would like to know the direction of the language design. 
>
>Thanks,
>
>Ko Fujimura, NTT

Date: Fri, 09 Mar 2001 22:17:48 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: [email-masked]
Cc: [email-masked], Rachel Willmer <[email-masked]>, [email-masked], [email-masked]

Ian Grigg wrote:
> 
> [email-masked] wrote:
> ...
> >
> > for some fsml related information
> >
> > http://www.echeck.org/
> 
> I printed out the 1.5.  The document formatting rules look like a
> useful starting point for XML contracts (including the Voucher
> work).
> 
> The rest of the document seems to be oriented to check processing.
> Even though it claims that it might be used for generic documents,
> I doubt it, as there are too many assumptions about how checks work
> built into it, as well as lots of protocol stuff.

Thank you for your advice. But, the FSML v1.5 spec also seems to be 
oriented to check processing.

By the way, I'm studying how to write your bond and currency defined 
in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
in XML voucher.

I think some of properties of the contract do not have to be interpreted 
by the program and they are defined only for clarifying its legal meaning. 
In case of bond, for example, bond_face, bond_currency, and 
bond_maturity_date are needed to be processed especially when it is 
redeemed. But, bond_issue_date and bond_total_issue_number seem to be 
defined only for clarifying its legal meaning, am I right?

I think that we do not have to introduce specific tags for these 
properties which are not interpreted by the software, since it is 
sufficient to write them in a plain text in "one" XML element such as 
<Contract>...</Contract>. I think it can be used as a criteria whether we 
introduce as an element in XML voucher or not.
How do you think this approach?

Regards,

Ko

Date: Fri, 09 Mar 2001 18:02:13 +0900
From: Ko Fujimura <[email-masked]>
Subject: IOTPV2: XML messaging
To: [email-masked]

In <http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp2-req-00.txt>:

> INTERNET-DRAFT            IOTP v2 Requirements             February 2001
> 
> 
> 1. Introduction
> 
>    Verion 2 of the Internet Open Trading Protocol (IOTP) will extend the
>    interoperable framework for Internet commerce capabilities of Version
>    1 [RFC 2801] as described in Section 3 below.  In addition, it will
>    replace the ad hoc XML messaging and digitial signature [RFC 2802]
>    parts of IOTP v1 with standards based mechanisms.

Which XML messaging protocols will be used for replacing current XML messaging?
Do you assume that ebXML TR/P for underlying protocol of IOTP version 2?
I would like to know the direction of the language design. 

Thanks,

Ko Fujimura, NTT

Date: Wed, 07 Mar 2001 11:53:39 -0800
From: "Lewis, Tony" <[email-masked]>
Subject: RE: ECML: clear field definitions appreciated
To: [email-masked]

On Wednesday, March 07, 2001 9:14 AM, Mia Lahteenmaki wrote:

> In another words, the protocol names on the list must 
> unambiquously reference to one protocol. 

I agree wholeheartedly.
 
> Like 'set' is for SET protocol and in the ECML spec a 
> reference to the SET specs can be given. 
> Both parties know exactly what it means. Merchant can 
> create a SET wakeup to start the process. 

Perhaps it would be better to use something like
http://www.setco.org/set/v1.0 instead of "set".
 
> Now there exist "protocol names" already in the list 
> that do not have unambiguous meaning, like "simcard" 
> and "phoneid". These values do not define any one protocol 
> or at least we have no reference to such protocols. 
> So if merchant receives these values from the wallet 
> what he should do next?  

We should get rid of the names that don't correlate to a specific protocol.
_________________________________________________________________
Tony Lewis ([email-masked])
Chief Systems Architect, Internet Commerce
Visa International Service Association

Date: Wed, 07 Mar 2001 19:14:05 +0200
From: [email-masked]
Subject: RE:RE: ECML: clear field definitions appreciated
To: [email-masked], [email-masked]

> On Tuesday 06. March 2001 18:51, Lewis, Tony wrote: 
> 
> On Tuesday, March 06, 2001 3:11 AM, Mia Lahteenmaki wrote:
> 
> > The fields that in my opinion do not fullfil the above 
> requirements at 
> > all are 1) Ecomm_Payment_Card_Protocol (some values still unclear, 
> > although Donald Eastlake has been admirably trying to get 
> some answers), 
> 
> I agree that the fields need to be clearly defined. However, on this
> particular field, the specification to allow new values for 
> the field to be
> created easily. When new payment protocols are created, it 
> should be easy to
> add the protocol so that the creators feel comfortable using 
> IOTP. Perhaps
> it is just a matter of creating a registrar for the values.
> _________________________________________________________________
> Tony Lewis ([email-masked])
> Chief Systems Architect, Internet Commerce
> Visa International Service Association

Good point. I was being unclear. 
I agree Tony that adding new protocols to the 
list should be easy. My intention on the particular 
field was that when introducing a new item value for 
the protocol field we can give 
a)a pointer to the protocol spec or 
b) say that this is a proprietary protocol that 
is not public and it is used by xxx systems. 

In another words, the protocol names on the list must 
unambiquously reference to one protocol. 

Like 'set' is for SET protocol and in the ECML spec a 
reference to the SET specs can be given. 
Both parties know exactly what it means. Merchant can 
create a SET wakeup to start the process. 

Now there exist "protocol names" already in the list 
that do not have unambiguous meaning, like "simcard" 
and "phoneid". These values do not define any one protocol 
or at least we have no reference to such protocols. 
So if merchant receives these values from the wallet 
what he should do next?  

I assume that the underlying assumption about the mobile
world has been that the customer is able to shop only in 
a closed operator network where both the customer and 
the merchant necessarily have contracts with the operator. 
Inside this network the meaning of these protocol names 
would then be unabiquously defined and everything would 
work fine.
With mobile access to internet e.g., via WAP this is not 
however true. 

Best Regards,
Mia    

Date: Tue, 06 Mar 2001 08:50:43 -0800
From: "Lewis, Tony" <[email-masked]>
Subject: RE: ECML: clear field definitions appreciated
To: [email-masked]

On Tuesday, March 06, 2001 3:11 AM, Mia Lahteenmaki wrote:

> The fields that in my opinion do not fullfil the above requirements at 
> all are 1) Ecomm_Payment_Card_Protocol (some values still unclear, 
> although Donald Eastlake has been admirably trying to get some answers), 

I agree that the fields need to be clearly defined. However, on this
particular field, the specification to allow new values for the field to be
created easily. When new payment protocols are created, it should be easy to
add the protocol so that the creators feel comfortable using IOTP. Perhaps
it is just a matter of creating a registrar for the values.
_________________________________________________________________
Tony Lewis ([email-masked])
Chief Systems Architect, Internet Commerce
Visa International Service Association

Date: Tue, 06 Mar 2001 13:11:14 +0200
From: [email-masked]
Subject: ECML: clear field definitions appreciated
To: [email-masked]

Hi,
Old ECML fields were self-explanatory, so they could be explained with a few
foot notes but the new fields require clear definitions, or otherwise the
spec looses its main aim. 

One requirement for the specification work could be that 
a)fields are well-defined in detail for any party to use or 
b)it is explicitly said that this is proprietary field and you can use it as
you like. So if we want to support proprietary work, that's also fine, but
let's do it openly then so that the whole point of spec is not lost.

The fields that in my opinion do not fullfil the above requirements at all
are
1) Ecomm_Payment_Card_Protocol (some values still unclear, although Donald
Eastlake has been admirably trying to get some answers), and 

2) Ecomm_Transaction_Signature field (Ecomm_Transaction_Signature) where the
footnote tells that 
"(31) The signature of the encoded certificate.  This is usually a hidden
field."
Huh? What does this mean?

3) Ones that are promised to be defined later :-)  We will hear about these
more soon I hope.

Best Regards
Mia Lahteenmaki

Date: Tue, 06 Mar 2001 19:18:05 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Contracts and XML Voucher
To: [email-masked]
Cc: [email-masked]

Hi Ian,

Thank you for your comments:

Ian Grigg wrote:
> 
> Ko Fujimura wrote:
...
> > Through the development of early version of this system, we learned importance
> > of standardization of "contract" or "value description language" that describes
> > what/how values/rights are traded between the trading partners.
> 
> Do you mean the term "contract" in its legal sense, or in the
> information sense?  That is, the law of contract applies, or,
> that the "contract" or interface is specified as per programming
> needs?

I used it in the legal sense, but rather weak meaning. In other words,
It can be used it legally if the issuer provides enough information within the 
Promise element. Using the XML-naming facility, any application-specific 
properties can be extended in the Merchandise element. For example:

<Promise>
  ...
  <Merchandise xmlns="http://www.example.org/bond.txt">
     <Bond identitiy="..." issueDate="..." .../>
  </Merchandise>
<Promise>

(I'm not sure tag name "Merchandise" is appropriate.) 

But, strictly speaking, it might be a fragment of a contract, since issuer's 
signature is attached externally as you pointed out.

> 
> If you mean the term in the sense of law and negotiating parties,
> I would wonder how the Voucher could stand up to a dispute?  In
> the Ricardian concept, we insist that the contract be readable
> by humans, linked to the asset in question, signed by the Issuer,

Right. Readability is an important issue of XML. Plain text is a good approach
in this sense. But, it was also discussed in the XMLDSIG WG and summary of the 
discussion is incorporated in Section 8 of the current XMLDSIG spec:
<http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/#sec-Security>.

> and some form of open PKI in operation that provides evidence of
> intention, and other devices to maintain the consistency of the
> contract under a wide degree of circumstances.

My basic idea is to leave this issue to other specification, i.e., XMLDSIG,
since it seems to be a general issue of XMLDSIG.
We haven't specified how <vts:KeyInfo> is used in the current draft.
But, one idea is to adopt/refer <KeyInfo> defined in the XMLDSIG spec as it is. 

Recently, the spec of KeyInfo have been discussed actively in the XMLDSIG WG.
(See archive below:)

"Donald E. Eastlake 3rd" wrote in: 
<http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0073.html>
 
> I think the various sides of this issue
> <http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0039.html>
> have been well argued and that it is unlikely there will be much
> furhter change in opinion.  The consensus of the Working Group is for
> option 2 and we will proceed on the basis of that choice.  This also
> means including clearer criterion as to when elements other than those
> we have defined can be included within the {X509|PGP|SPKI}Data
> element.
> 
> I suggest the text in the editors draft at
> <http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-KeyInfo>
> be changed to be the HTML appended below.

Regards, 

Ko

Date: Mon, 05 Mar 2001 11:22:25 -0800
From: [email-masked]
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: [email-masked]
Cc: Ko Fujimura <[email-masked]>, Rachel Willmer <[email-masked]>, [email-masked], [email-masked]

as an aside, X9.59 financial standard that recently passed (electronic standard
for all retail payments) also incorporates the message digest of the purchase
order (or contract) in the body of the payment message.

as specified in the standard, the payment message encoding format is ASN.1 ...
however the appendix includes an example in FSML (financial standards markup
language ... precursor to much of the XML financial related specifications).

financial standards bodys are at

http://www.x9.org/
http://www.tc68.org/

for some fsml related information

http://www.echeck.org/

misc. x9.59 information

http://www.garlic.com/~lynn/

Ian Grigg <[email-masked]> on 03/05/2001 08:59:35 AM

Please respond to [email-masked]

To:   Ko Fujimura <[email-masked]>
cc:   Rachel Willmer <[email-masked]>, [email-masked],
      [email-masked]
Subject:  Re: implementations of "XML Voucher: Generic Voucher Language" ?

That's an interesting point.  In our system, the identity of the
contract is provided by a canonical message digest (calculated
over the readable contract) which is used as the identifier in
payments.  There is nothing in the SOX protocol that limits the
usage to that digest, and nothing in the Ricardian Contract that
says which protocol to use (and indeed, it is possible to plugin
a separate payment system into WebFunds, and use Ricardian Contracts),
it's mostly an implementation issue.

However, there is ample flexibility in the contract format, and
indeed, any similar format like your XML Voucher one, to add a
limitation of protocol.  That might become interesting in the
future as we are adding different transaction types to WebFunds
as a background task, and are using Ricardian Contracts in areas
that don't involve SOX directly.

--
iang

Date: Mon, 05 Mar 2001 12:59:35 -0400
From: Ian Grigg <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
Sender: [email-masked]
To: Ko Fujimura <[email-masked]>
Cc: Rachel Willmer <[email-masked]>, [email-masked], [email-masked]
Reply-to: [email-masked]

Ko Fujimura wrote:
> 
> Hi Rachel,
> 
> > Are you familiar with Systemics Ricardo system, which uses Ricardian
> > contracts to implement the concept that you call "vouchers"?
> >
> > <http://www.systemics.com>
> >
> > This system has been around for about 5 years and has been used in the
> > fields of currency, stocks and bonds. The use of "Ricardian contracts" or
> > "vouchers" is a critical part of the architecture.
> 
> Yes, I read his paper presented at FC'00 about one year ago. I like the design of
> the Ricardo system since it provides both flexibility and simplicity using modular
> software components.

Thanks!  The paper is at http://www.iang.org/papers/ and the
software mentioned is at http://www.webfunds.org/ .

> > We're in the process of integrating their Ricardo system into our
> > CashBox(tm) system, and I'm interested in knowing about any other companies
> > who may be implementing other payment systems based on these concepts, so
> > please do let me know when others do implement.
> 
> Our FlexTicket system is a smartcard-based value/rights circulation system and
> provides transferability and offline capability. There are more information on
> the protocols presented at CARDIS 2000.
> <http://info.isl.ntt.co.jp/flexticket/papers/>

I had a look through this yesterday and put some information
on the proposal, as an 'alternate' to our Ricardian contract
concept, up on the webfunds site:

    http://www.webfunds.org/guide/ricardian.html

What is very interesting to us is that we may be able to use
your formats for the Ricardian Contract in XML -- it is a future
task for us to convert to the XML world for all the normal
reasons.

(The comparison come across as a little unfavourable because
it tries to measure the Voucher against our own internal
contracting requirements, which are accepted as being quite
fierce!).

> Through the development of early version of this system, we learned importance
> of standardization of "contract" or "value description language" that describes
> what/how values/rights are traded between the trading partners.

Do you mean the term "contract" in its legal sense, or in the
information sense?  That is, the law of contract applies, or,
that the "contract" or interface is specified as per programming
needs?

If you mean the term in the sense of law and negotiating parties,
I would wonder how the Voucher could stand up to a dispute?  In
the Ricardian concept, we insist that the contract be readable
by humans, linked to the asset in question, signed by the Issuer,
and some form of open PKI in operation that provides evidence of
intention, and other devices to maintain the consistency of the
contract under a wide degree of circumstances.

(Although, we are mostly concerned with English common law contracts,
I haven't got a view as to how they stand up in other legal domains.)

> We are going to implement XML voucher as soon as it completed.

You may find the framework in WebFunds to be of interest.  There,
we have a contract browser that reads in the contracts, verifies
the signatures, and can display the text.  There is also a nice
contract signing wizard that takes you through the process of
doing your own contract.  It's early days yet, this is really an
automation tool rather than a replacement for the complicated
process of underwriting;  it doesn't give you enough help in order
to write your own contract, if just automates some of the tasks
that are bothersome.

> By the way, I think that generic value transfer protocols like the Ricardo' SOX
> protocols are exciting and important. But, I think it is difficult to cover all
> application area using one universal value transfer protocol. We therefore think
> that "contract" should contain a parameter that specify which the protocols
> (or "VTS provider" in XML Voucher) are used. I think it will help to develop
> generic digital wallet like your CashBox(tm).

That's an interesting point.  In our system, the identity of the
contract is provided by a canonical message digest (calculated
over the readable contract) which is used as the identifier in
payments.  There is nothing in the SOX protocol that limits the
usage to that digest, and nothing in the Ricardian Contract that
says which protocol to use (and indeed, it is possible to plugin
a separate payment system into WebFunds, and use Ricardian Contracts),
it's mostly an implementation issue.

However, there is ample flexibility in the contract format, and 
indeed, any similar format like your XML Voucher one, to add a
limitation of protocol.  That might become interesting in the
future as we are adding different transaction types to WebFunds
as a background task, and are using Ricardian Contracts in areas
that don't involve SOX directly.

-- 
iang

Date: Mon, 05 Mar 2001 15:27:24 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Instance and Definition of Voucher
To: Raghuram Rajah <[email-masked]>
Cc: [email-masked]

Raghuram Rajah wrote:

> A few thoughts about the Voucher definition.
> 
> 4. Component Structure - Defining the components associated with the voucher
> itself (like ValidPeriod), seem to constraint the potential of the voucher.
> Wouldn't it be better to define a overall framework that can support an
> ability to define meta-data and behaviour. We can standardize some meta-data
> like ValidPeriod, but the issuer should be able to define more.
> 
> Also, in one of Ko's earlier presentation (when discussing requirements), I
> saw a division of the voucher into two parts - Definition and the actual
> voucher. I felt the approach was admirable, for it provided a mechanism to
> define the shape of the voucher and the data as two seperate entities.Making
> a distinction between the core voucher and the meta-description information,
> helps a lot when the voucher has to be stored on a limited device like the
> smart card.
> 
> We had built a "voucher" (we called it coupon) system for the smart card.
> Let me go over that design philosophy, which are in line with one of Ko's
> earlier presentation. Thus, I would think the voucher is defined by two
> entities,
> 
> - Voucher Definition. Defines the shape and behaviour of the voucher.
> - Voucher Instance. The core data of the voucher based on the defintion.

In the XML voucher document (Page 2), there is a description:

     Note: This document uses a "voucher" as an "instance of voucher"
     whose meaning is defined by Voucher Component. In other words,
     multiple vouchers can be issued and managed by the VTS using the
     same Voucher Component.

It might not be clear enough. But, I use "Voucher Component" as the meaning 
of "Voucher Definition". So, the current document already assumes the 
separation of the Definition and Instance. But, values of properties 
are also specified in the Definition if the value is fixed across the same 
type of the voucher as you pointed out.

The Voucher Component is used to make consensus between trading partners 
what/how the voucher are traded. In this sense, I think that the contents 
of voucher should be exchanged between the trading partners before actual 
"delivery of voucher instance" or "rewrite of the ownership". In this sense,
it should be specific enough so that trading partners can agree the item to 
be traded. I use Voucher *Component* since it might be used in offer exchange 
or other trading transactions.

The "instance of voucher", on the other hand, can be implemented as the 
identifier (or hash) of the Voucher Component if the Voucher Component is 
specific enough. This approach is key to achieving implementation flexibility 
and efficiency. 

By the way, the data structure of the "instance of voucher" is completely left 
to the VTS implementation. It may includes some VTS-specific parameters needed 
for preventing duplicate redemption, etc.

> 
> The Voucher Definition defines the genre of coupon,
> 
> eg. x% off any purchase greater than $y between m1/d1/y1 and m2/d2/y2 - Defn
> A
>     $x off purchase at YYY Store - Defn B
> 
> The Voucher Instance on the other hand is the actual coupon that specifies
> the values of variables,
> 
> eg. Coupon Defn A; x=5; y=25; m1/d1/y1 = 11/2/2000; m2/d2/y2 = 12/25/2000
>     Coupon Defn B; x=25; YYY = Sears
> 

Both of these Definition and Instance are considered as Voucher Component in my 
definition. But, I think it is possible to introduce such a layered definition 
within Voucher Component. It introduces, however, more implementation complexity. 
So, I didn't include this facility in the first version of the draft specification.

Thanks.

Ko

Date: Mon, 05 Mar 2001 11:05:38 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: Rachel Willmer <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

Hi Rachel,

> Are you familiar with Systemics Ricardo system, which uses Ricardian
> contracts to implement the concept that you call "vouchers"?
>
> <http://www.systemics.com>
>
> This system has been around for about 5 years and has been used in the
> fields of currency, stocks and bonds. The use of "Ricardian contracts" or
> "vouchers" is a critical part of the architecture.

Yes, I read his paper presented at FC'00 about one year ago. I like the design of 
the Ricardo system since it provides both flexibility and simplicity using modular 
software components.

>
> I've copied this mail to Ian Grigg from Systemics <[email-masked]>,
> because I think it may be worth you both engaging in some dialogue.

Thank you.

>
> We're in the process of integrating their Ricardo system into our
> CashBox(tm) system, and I'm interested in knowing about any other companies
> who may be implementing other payment systems based on these concepts, so
> please do let me know when others do implement.

Our FlexTicket system is a smartcard-based value/rights circulation system and 
provides transferability and offline capability. There are more information on 
the protocols presented at CARDIS 2000. 
<http://info.isl.ntt.co.jp/flexticket/papers/>

Through the development of early version of this system, we learned importance 
of standardization of "contract" or "value description language" that describes 
what/how values/rights are traded between the trading partners. 
We are going to implement XML voucher as soon as it completed.

By the way, I think that generic value transfer protocols like the Ricardo' SOX 
protocols are exciting and important. But, I think it is difficult to cover all 
application area using one universal value transfer protocol. We therefore think 
that "contract" should contain a parameter that specify which the protocols 
(or "VTS provider" in XML Voucher) are used. I think it will help to develop 
generic digital wallet like your CashBox(tm).

Regards,

Ko
----------------------------------------------------------
Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-2241
Email: [email-masked]

Date: Fri, 02 Mar 2001 10:20:47 -0500
From: Raghuram Rajah <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-trade-voucher-lang-00.txt
To: [email-masked]

Hi,

A few thoughts about the Voucher definition.

4. Component Structure - Defining the components associated with the voucher 
itself (like ValidPeriod), seem to constraint the potential of the voucher. 
Wouldn't it be better to define a overall framework that can support an 
ability to define meta-data and behaviour. We can standardize some meta-data 
like ValidPeriod, but the issuer should be able to define more.

Also, in one of Ko's earlier presentation (when discussing requirements), I 
saw a division of the voucher into two parts - Definition and the actual 
voucher. I felt the approach was admirable, for it provided a mechanism to 
define the shape of the voucher and the data as two seperate entities.Making 
a distinction between the core voucher and the meta-description information, 
helps a lot when the voucher has to be stored on a limited device like the 
smart card.

We had built a "voucher" (we called it coupon) system for the smart card. 
Let me go over that design philosophy, which are in line with one of Ko's 
earlier presentation. Thus, I would think the voucher is defined by two 
entities,

- Voucher Definition. Defines the shape and behaviour of the voucher.
- Voucher Instance. The core data of the voucher based on the defintion.

The Voucher Definition defines the genre of coupon,

eg. x% off any purchase greater than $y between m1/d1/y1 and m2/d2/y2 - Defn 
A
    $x off purchase at YYY Store - Defn B

The Voucher Instance on the other hand is the actual coupon that specifies 
the values of variables,

eg. Coupon Defn A; x=5; y=25; m1/d1/y1 = 11/2/2000; m2/d2/y2 = 12/25/2000
    Coupon Defn B; x=25; YYY = Sears

One of our initial XML DTDs looked like this,

CouponInstance DTD
~~~~~~~~~~~~~~~~~~

<!DOCTYPE BlueCoupon [

  <!ELEMENT BlueCoupon (CouponDefinition, Value, Constraint*,
			Signature?, CouponData?,
			Keyword?)>
  <!ATTLIST BlueCoupon ID #REQUIRED>    <!-- Numeric, upto 13 digits -->

  <!ELEMENT CouponDefinition (CouponProviderID, CouponDefinitionID)>
  <!ELEMENT CouponProviderID (#PCDATA)>  <!-- Numeric, upto 5 digits -->
  <!ELEMENT CouponDefinitionID (#PCDATA) <!-- Numeric, upto 8 digits -->

  <!ELEMENT Value (#PCDATA)             <!-- Numeric, 32-bit unsigned -->

  <!ELEMENT Constraint (#PCDATA)>       <!-- data type specified in the 
Definition -->
  <!ATTLIST Constraint ID #REQUIRED>    <!-- Numeric 16-bit, Unique, should 
be present in Defn-->

  <!ELEMENT Signature (#PCDATA)         <!-- doesn't include keywords -->
  <!ELEMENT CouponData (#PCDATA)	<!-- user data, optional -->

  <!ELEMENT Keyword ANY>                <!-- defined by the Provider -->

]>

CouponDefinition DTD
~~~~~~~~~~~~~~~~~~~~

<!DOCTYPE BlueCouponDefinition [

  <!ELEMENT BlueCouponDefinition (CouponType, ConstraintDefn*,
                                  Resource?, SignatureProperties)>
  <!ATTLIST BlueCouponDefinition ID #REQUIRED>      <!-- Numeric, upto 8 
digits -->

  <!ELEMENT CouponType (Stateful?, ValueType)>
  <!ELEMENT Stateful EMPTY>
  <!ELEMENT ValueType (#PCDATA)> <!-- Type to be understood by the using 
system -->

  <!ELEMENT ConstraintDefn (Name?, Description?, Type, Behaviour)>
  <!ATTLIST ID #REQUIRED>        <!-- This is used to specify values in the 
instance,
                                      and should be sequential for 
bluecoupon -->
  <!ELEMENT Name (#PCDATA)>
  <!ELEMENT Description (#PCDATA)>
  <!ELEMENT Type (Scalar | Currency | Floating | Date | String | Int32 | 
Int16)>
  <!ELEMENT Behaviour (Equal | NotEqual | Greater | GreaterEqual | Lesser | 
LesserEqual)

  <!ELEMENT Resource (Promise?, Icon?)>
  <!ELEMENT Promise (#PCDATA)>   <!-- url for the textual description of the 
promise -->
  <!ELEMENT Icon (#PCDATA)>      <!-- url for the icon associated with the 
promise -->

  <!ELEMENT SignatureProperties (SignatureMethod)> <!-- we might have to 
include the
                                                       encryption key too 
here, lets see -->
  <!ELEMENT SignatureMethod (#PCDATA)> <!-- method understood by using 
system
                                            like SHA-1 or MD5 -->

]>

EXAMPLE
~~~~~~~

<BlueCouponDefinition ID=78698563>
<CouponType>
  <ValueType>Percent</ValueType>
</CouponType>

<ConstraintDefn ID=1>
  <Name> MinPurchaseInCurrency </Name>
  <Type> Currency </Type>
</ConstraintDefn>

<ConstraintDefn ID=2>
  <Name> ValidityEndDate </Name>
  <Type> Date </Type>
</ConstraintDefn>

<ConstraintDefn ID=3>
  <Name> Vendor </Name>
  <Type> Numeric-5 </Type>
</ConstraintDefn>

<SignatureProperties>
  <SignatureMethod>SHA-1</SignatureMethod>
</SignatureProperties>
</BlueCouponDefinition>

<BlueCoupon ID=36948935845189>
<CouponDefinition>
  <CouponProviderID>12345</CouponProviderID>
  <CouponDefinitionID>78698563</CouponDefinitionID>
</CouponDefinition>

<Value>20</Value>

<Constraint ID=1>50</Constraint>
<Constraint ID=2>12/20/2000</Constraint>
<Constraint ID=3>45282</Constraint>

<Signature>94675745756756772</Signature>

<Keyword>
  <Category>General Merchandise
</Keyword>
</BlueCoupon>

Common Keywords/Constraints
~~~~~~~~~~~

Keywords
  - Category
  - Zipcode
  - City

Constraints
  - Product
  - Vendor
  - ValidityStartDate
  - ValidityEndDate
  - MaxUsageCount
  - Circulation
  - MinPurchaseCurrency
  - MaxPurchaseCurrency
  - MinPurchaseQty
  - MaxPurchaseQty
  - MaxCouponValue

>From: [email-masked]
>Reply-To: [email-masked]
>To: IETF-Announce: ;
>CC: [email-masked]
>Subject: I-D ACTION:draft-ietf-trade-voucher-lang-00.txt
>Date: Thu, 22 Feb 2001 07:04:37 -0500
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Internet Open Trading Protocol Working 
>Group of the IETF.
>
>	Title		: XML Voucher: Generic Voucher Language
>	Author(s)	: K. Fujimura
>	Filename	: draft-ietf-trade-voucher-lang-00.txt
>	Pages		: 8
>	Date		: 21-Feb-01
>
>This document specifies rules for defining voucher properties in
>XML syntax. A voucher is a logical entity that represents a right
>to claim goods or services. A voucher can be used to transfer a
>wide-range of electronic-values, including coupons, tickets,
>loyalty points, and gift certificates, which are often necessary to
>process in the course of payment and/or delivery transactions.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-lang-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-trade-voucher-lang-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-trade-voucher-lang-00.txt".
>
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
><< attach3 >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Date: Fri, 02 Mar 2001 10:20:36 -0500
From: Raghuram Rajah <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-trade-voucher-lang-00.txt
To: [email-masked]

Hi,

A few thoughts about the Voucher definition.

4. Component Structure - Defining the components associated with the voucher 
itself (like ValidPeriod), seem to constraint the potential of the voucher. 
Wouldn't it be better to define a overall framework that can support an 
ability to define meta-data and behaviour. We can standardize some meta-data 
like ValidPeriod, but the issuer should be able to define more.

Also, in one of Ko's earlier presentation (when discussing requirements), I 
saw a division of the voucher into two parts - Definition and the actual 
voucher. I felt the approach was admirable, for it provided a mechanism to 
define the shape of the voucher and the data as two seperate entities.Making 
a distinction between the core voucher and the meta-description information, 
helps a lot when the voucher has to be stored on a limited device like the 
smart card.

We had built a "voucher" (we called it coupon) system for the smart card. 
Let me go over that design philosophy, which are in line with one of Ko's 
earlier presentation. Thus, I would think the voucher is defined by two 
entities,

- Voucher Definition. Defines the shape and behaviour of the voucher.
- Voucher Instance. The core data of the voucher based on the defintion.

The Voucher Definition defines the genre of coupon,

eg. x% off any purchase greater than $y between m1/d1/y1 and m2/d2/y2 - Defn 
A
    $x off purchase at YYY Store - Defn B

The Voucher Instance on the other hand is the actual coupon that specifies 
the values of variables,

eg. Coupon Defn A; x=5; y=25; m1/d1/y1 = 11/2/2000; m2/d2/y2 = 12/25/2000
    Coupon Defn B; x=25; YYY = Sears

One of our initial XML DTDs looked like this,

CouponInstance DTD
~~~~~~~~~~~~~~~~~~

<!DOCTYPE BlueCoupon [

  <!ELEMENT BlueCoupon (CouponDefinition, Value, Constraint*,
			Signature?, CouponData?,
			Keyword?)>
  <!ATTLIST BlueCoupon ID #REQUIRED>    <!-- Numeric, upto 13 digits -->

  <!ELEMENT CouponDefinition (CouponProviderID, CouponDefinitionID)>
  <!ELEMENT CouponProviderID (#PCDATA)>  <!-- Numeric, upto 5 digits -->
  <!ELEMENT CouponDefinitionID (#PCDATA) <!-- Numeric, upto 8 digits -->

  <!ELEMENT Value (#PCDATA)             <!-- Numeric, 32-bit unsigned -->

  <!ELEMENT Constraint (#PCDATA)>       <!-- data type specified in the 
Definition -->
  <!ATTLIST Constraint ID #REQUIRED>    <!-- Numeric 16-bit, Unique, should 
be present in Defn-->

  <!ELEMENT Signature (#PCDATA)         <!-- doesn't include keywords -->
  <!ELEMENT CouponData (#PCDATA)	<!-- user data, optional -->

  <!ELEMENT Keyword ANY>                <!-- defined by the Provider -->

]>

CouponDefinition DTD
~~~~~~~~~~~~~~~~~~~~

<!DOCTYPE BlueCouponDefinition [

  <!ELEMENT BlueCouponDefinition (CouponType, ConstraintDefn*,
                                  Resource?, SignatureProperties)>
  <!ATTLIST BlueCouponDefinition ID #REQUIRED>      <!-- Numeric, upto 8 
digits -->

  <!ELEMENT CouponType (Stateful?, ValueType)>
  <!ELEMENT Stateful EMPTY>
  <!ELEMENT ValueType (#PCDATA)> <!-- Type to be understood by the using 
system -->

  <!ELEMENT ConstraintDefn (Name?, Description?, Type, Behaviour)>
  <!ATTLIST ID #REQUIRED>        <!-- This is used to specify values in the 
instance,
                                      and should be sequential for 
bluecoupon -->
  <!ELEMENT Name (#PCDATA)>
  <!ELEMENT Description (#PCDATA)>
  <!ELEMENT Type (Scalar | Currency | Floating | Date | String | Int32 | 
Int16)>
  <!ELEMENT Behaviour (Equal | NotEqual | Greater | GreaterEqual | Lesser | 
LesserEqual)

  <!ELEMENT Resource (Promise?, Icon?)>
  <!ELEMENT Promise (#PCDATA)>   <!-- url for the textual description of the 
promise -->
  <!ELEMENT Icon (#PCDATA)>      <!-- url for the icon associated with the 
promise -->

  <!ELEMENT SignatureProperties (SignatureMethod)> <!-- we might have to 
include the
                                                       encryption key too 
here, lets see -->
  <!ELEMENT SignatureMethod (#PCDATA)> <!-- method understood by using 
system
                                            like SHA-1 or MD5 -->

]>

EXAMPLE
~~~~~~~

<BlueCouponDefinition ID=78698563>
<CouponType>
  <ValueType>Percent</ValueType>
</CouponType>

<ConstraintDefn ID=1>
  <Name> MinPurchaseInCurrency </Name>
  <Type> Currency </Type>
</ConstraintDefn>

<ConstraintDefn ID=2>
  <Name> ValidityEndDate </Name>
  <Type> Date </Type>
</ConstraintDefn>

<ConstraintDefn ID=3>
  <Name> Vendor </Name>
  <Type> Numeric-5 </Type>
</ConstraintDefn>

<SignatureProperties>
  <SignatureMethod>SHA-1</SignatureMethod>
</SignatureProperties>
</BlueCouponDefinition>

<BlueCoupon ID=36948935845189>
<CouponDefinition>
  <CouponProviderID>12345</CouponProviderID>
  <CouponDefinitionID>78698563</CouponDefinitionID>
</CouponDefinition>

<Value>20</Value>

<Constraint ID=1>50</Constraint>
<Constraint ID=2>12/20/2000</Constraint>
<Constraint ID=3>45282</Constraint>

<Signature>94675745756756772</Signature>

<Keyword>
  <Category>General Merchandise
</Keyword>
</BlueCoupon>

Common Keywords/Constraints
~~~~~~~~~~~

Keywords
  - Category
  - Zipcode
  - City

Constraints
  - Product
  - Vendor
  - ValidityStartDate
  - ValidityEndDate
  - MaxUsageCount
  - Circulation
  - MinPurchaseCurrency
  - MaxPurchaseCurrency
  - MinPurchaseQty
  - MaxPurchaseQty
  - MaxCouponValue

>From: [email-masked]
>Reply-To: [email-masked]
>To: IETF-Announce: ;
>CC: [email-masked]
>Subject: I-D ACTION:draft-ietf-trade-voucher-lang-00.txt
>Date: Thu, 22 Feb 2001 07:04:37 -0500
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Internet Open Trading Protocol Working 
>Group of the IETF.
>
>	Title		: XML Voucher: Generic Voucher Language
>	Author(s)	: K. Fujimura
>	Filename	: draft-ietf-trade-voucher-lang-00.txt
>	Pages		: 8
>	Date		: 21-Feb-01
>
>This document specifies rules for defining voucher properties in
>XML syntax. A voucher is a logical entity that represents a right
>to claim goods or services. A voucher can be used to transfer a
>wide-range of electronic-values, including coupons, tickets,
>loyalty points, and gift certificates, which are often necessary to
>process in the course of payment and/or delivery transactions.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-lang-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-trade-voucher-lang-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-trade-voucher-lang-00.txt".
>
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
><< attach3 >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Date: Fri, 02 Mar 2001 14:37:01 +0000
From: Rachel Willmer <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: Ko Fujimura <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

Rachel Willmer wrote on the IETF IOTP mailing list:

>> Have there been any implementations of this Internet Draft on "XML
>> Voucher: Generic Voucher Language" ?

On 01 March 2001 14:29 +0900 Ko Fujimura <[email-masked]> replied

> Not yet. This document is newly designed and not completed as you see
> t.b.s.  sections. If major design issues are acceptable for the WG
> members, we would  like to go into detail.
>
> But I think it is easy to implement on top of existing value transfer
> protocols since we designed it based on our implementation experiences of
> several types  of value transfer protocols and languages. I hope some
> volunteers could also  help to check feasibility and give feedback about
> the specification.

Ko

Are you familiar with Systemics Ricardo system, which uses Ricardian 
contracts to implement the concept that you call "vouchers"?

	<http://www.systemics.com>

This system has been around for about 5 years and has been used in the 
fields of currency, stocks and bonds. The use of "Ricardian contracts" or 
"vouchers" is a critical part of the architecture.

I've copied this mail to Ian Grigg from Systemics <[email-masked]>, 
because I think it may be worth you both engaging in some dialogue.

We're in the process of integrating their Ricardo system into our 
CashBox(tm) system, and I'm interested in knowing about any other companies 
who may be implementing other payment systems based on these concepts, so 
please do let me know when others do implement.

Regards
Rachel

Date: Thu, 01 Mar 2001 14:29:20 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: Rachel Willmer <[email-masked]>
Cc: [email-masked]

Rachel Willmer wrote:
> 
> Have there been any implementations of this Internet Draft on "XML Voucher:
> Generic Voucher Language" ?
> 
> Thanks
> Rachel

Not yet. This document is newly designed and not completed as you see t.b.s. 
sections. If major design issues are acceptable for the WG members, we would 
like to go into detail.

But I think it is easy to implement on top of existing value transfer protocols
since we designed it based on our implementation experiences of several types 
of value transfer protocols and languages. I hope some volunteers could also 
help to check feasibility and give feedback about the specification.

Thanks,

Ko

Date: Fri, 30 Mar 2001 09:37:34 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: TRADE WG Mailing List Archives URL
To: [email-masked]
Cc: [email-masked]

Hi,

The mailing list archives URL given on the WG Charter Page and in some
drafts is incorrect.  The correct URL is

	    http://lists.eListX.com/archives/ietf-trade
           ^^^^^

I'm working on getting the Charter Page fixed and drafts will be
udated as they are revised...

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)

Date: Wed, 28 Mar 2001 15:23:27 -0500
From: Donald Eastlake 3rd <[email-masked]>
Subject: draft Minutes from 50th IETF
Sender: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]

Hi,

Below are the draft minutes.  Thanks to Walt Houser.

Donald
==================================================================
 Donald Eastlake 3rd  +1 508-634-2066(h)  [email-masked]
 155 Beaver Street    +1 508-261-5434(w)  [email-masked]
 Milford, MA 01757 USA

Internet Open Trading Protocol Working Group (WG) - TRADE
Minutes of meeting in Minneapolis at the 50th IETF Meeting

WEDNESDAY, March 21 at 1300-1500
================================

CHAIR:	Donald E. Eastlake 3rd <[email-masked]> 
REPORTER:  Walter Houser <[email-masked]>
edits: Donald E. Eastlake 3rd.

Agenda Bashing - no change.

Documents Status - Don presented his report, which appear in the
slides that will be submitted to the proceedings.  Three documents
have in working group last call for some time:
draft-ietf-trade-iotp-v1.0-papi-03.txt,
draft-ietf-trade-iotp-v1.0-set-02.txt, and
draft-ietf-trade-drt-requirements-02.txt.  Due to comments during WG
last call, the title Digital Rights has been changed to Voucher in the
drt-requirements draft.  Minor edits for readability have been made in
the papi-03 draft producing papi-04 which is available from
<ftp://ftp.pothole.com/pub/ietf-trade/> and will shortly be posted in
the IETF Internet-Draft directories.  The consensus among those at the
WG meeting was to submit these for publication as Informational RFCs.

Don listed the existing drafts currently under consideration:
draft-ietf-trade-voucher-lang-00.txt,
draft-ietf-trade-ecml2-req-00.txt, draft-ietf-trade-ecml2-spec-00.txt,
draft-ietf-trade-iotp2-req-00.txt.  The ECML Version 2 requirements
document is fairly close to final but the others need work.

Two WG documents are called for that do not yet exist:

1) Secure Channel Credit Debit, a payment method of equivalent
security to HTML forms.  Don suggested this might be accomplished by
light encapsulation of ECML.  There were no objections at the meeting
to this approach.

2) IOTP v2 specification, scheduled for April, no author yet which
makes meeting that milestone pretty unlikely...

Tony Lewis requested that updated milestone dates be posted in the
WG's IETF web page.  Don will look into the Charter change that would
require.

IOTP/ECML Implementation Experience - Don reported that these include
the V1 IOTP Japanese SMILE project.  There is a partial list of
merchant sites at http://www.ecml.org/, but the list needs to be
updated. It notes the IBM wallet and the Microsoft wallet.

ECML V2 Requirements - Is this ready for last call?  Don plans a last
call in a month. V1 was HTML form oriented, whereas v2 is to be XML
oriented.  Comments solicited.

ECML V2 Specification - ISO 8583 fields being added.  Dave Shepherd of
IBM (mailto:[email-masked]) suggested incorporating changes for
Java Commerce messages (JCM). JCM uses lineItems, which do not appear
in ECML v2. We currently don't have a namespace for ECML. V1 has a DTD
but no schema or namespace. Parsons has added fields for v2.
	What syntax do we use to ask for missing data? When asking for
data, how do we indicate whether the request is Optional or mandatory?

XML Voucher: Generic Voucher Language - Ko Fujimura of NTT
(mailto:[email-masked]) presented background on voucher and
current status. Voucher component is not an instance but a definition
of voucher. VC defines the rights (or value) per one unit of the
voucher instance. Ko outlined the processing model (see slides). Ko
plans to publish an API. He is proposing a new trust model based on
the voucher components (see slides). The monetary value properties are
needed to calculating the redemption. His studies suggest that 90
percent of vouchers can be provided using three or four properties:

1. Minimum number of vouchers needed for redemption
2. Merchandise limitation
3. Merchandise value can be specified in as fixed or percentage of
discount. 

An xml:ns is specified. Proposed actions for April include
Internet-Draft on XML voucher and submit Internet-Draft on VTS
(Voucher Trading System) API.  Although much discussion on voucher, no
major issues so far. Ko asked how should we proceed with specifying
the VTS API?

Don noted that our past experience in specifying an API in XML was not
satisfactory. But a Java or C binding is reasonable. As the author
provides the dates, he saw no problem. There were no other comments.

IOTP V2 Requirements - Version 2 is to be a superset of v1 (but not
necessarily backward compatible), dynamic definition of trading
sequences, offer request block, improved problem resolution, handle
payment protocols not tunneled through IOTP, say via TCP.  Optional
items include support for wallet servers, repeated or ongoing in
payment, enhance server to server (timing of submissions to the
payment handler), and the ability to add both fields and attributes to
trading blocks. Not to be included are legal and regulatory issues,
the XML messaging layer, and XML digital signature.  Perhaps a profile
on these standards use with IOTP V2 may in order.

Walt Houser asked which XML messaging layer would be used? Don replied
that was to be decided but he thought ebXML was a bit ahead.  Walt
noted that ebXML uses SOAP rather than BEEP. SOAP is an industry
consortia protocol that competes with the IETF BEEP standard.

Tony Lewis asked if there is anything in the way of the digital
signature becoming a standard?  Don replied that the work of the joint
IETF/W3C XML Digital Signature Work Group is currently a Proposed
Standard in the IETF and a Candidate Recommendation in the W3C.  The
W3C plans to make it a full RECommendation abut the time the IETF
should be advancing it to Draft Standard.  It is unclear when the IETF
will further advance it to Full Internet Standard because this
requires widespread deployment.

Ko asked how would one approach dynamic definition of trading
sequences. Don replied describing one method, which has been partially
specified by Dave Burdett, where the merchant proposes the structure
of the trade along with the prices and currencies, etc.

Schedule of Future Actions/Meetings -

1) Authors are needed for SCCD and IOTP v2 specification

2) The WG will meet in London in early August and until then continue
work on the mailing list.

The WG meeting adjourned at 14:22

Date: Wed, 28 Mar 2001 12:37:55 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: Comment on draft-ietf-trade-iotp2-req-00.txt
To: Walt Houser <[email-masked]>
Cc: [email-masked]

Hi,

From:  Walt Houser <[email-masked]>
Date:  Wed, 21 Mar 2001 10:18:37 -0800 (PST)
To:  [email-masked], Walter Houser <[email-masked]>
Message-id:  <[email-masked]>

>The ID states:
>
>   The following are out of scope for IOTP version 2:
>
>   1. Legal or regulatory issues surrounding the
>      implementation of the
>      protocol or information systems using it.
>
>   2. Design of an XML Messaging Layer.
>
>wh: Should the ID point to BXXP? SOAP? XP?

It could but I don't think it is necessary for the requirmeents draft
to specify the particular Messaging to be used.  It is also not clear
to me how soon this will settle out and whether people will gravitate
towards one method or a few...making it hard to give a specific
pointer.

>   3. Design of XML Digitial Signatures.
>
>wh: Should the ID point to XMLDS?
>http://www.w3.org/TR/xmldsig-core/ 

Similarly, I don't think it has to.  But in this case, the standard
has been adopted and the ID might as well give a reference.  Since
this is an IETF effort, it should point to the RFC which should be out
any day now...

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd                    [email-masked]
 155 Beaver Streeet                         [email-masked]
 Milford, MA 01757 USA     +1 508-634-2066(h)   +1 508-261-5434(w)

Date: Mon, 26 Mar 2001 18:25:52 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Comments on Attributes/Elements
To: Walter Houser <[email-masked]>
Cc: IETF Trade <[email-masked]>

Hi Walt,

There are a number of viewpoints regarding this question as you see:

  http://xml.coverpages.org/elementsAndAttrs.html

I have no strong preference, but I prefer attribute to element for 
describing short contents as we do in IOTP or ECML, e.g., BrandName, 
ProtocolName, WalletID, ...

Walt Houser wrote:
> 
> Why use attributes
> 
>      <Provider Name="Voucher Wallet 2001">
>        <vts:KeyInfo>...</vts:KeyInfo>
>      </Provider>
>      <Issuer Name="Alice Book Center, Ltd.">
>        <vts:KeyInfo>...</vts:KeyInfo>
>      </Issuer>
> 
> instead of elements?
> 
>      <Provider>
>      <Name>Voucher Wallet 2001</Name>
>        <vts:KeyInfo>...</vts:KeyInfo>
>      </Provider>
>      <Issuer>
>      <Name>Alice Book Center, Ltd.</Name>
>        <vts:KeyInfo>...</vts:KeyInfo>
>      </Issuer>

Regards,

Ko
----------------------------------------------------------
Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-2241
Email: [email-masked]

Date: Wed, 21 Mar 2001 11:05:58 -0800 (PST)
From: Walt Houser <[email-masked]>
Subject: Comments on
To: IETF Trade <[email-masked]>
Cc: Walter Houser <[email-masked]>

Why use attributes 

     <Provider Name="Voucher Wallet 2001">
       <vts:KeyInfo>...</vts:KeyInfo>
     </Provider>
     <Issuer Name="Alice Book Center, Ltd.">
       <vts:KeyInfo>...</vts:KeyInfo>
     </Issuer>

instead of elements?

     <Provider>
     <Name>Voucher Wallet 2001</Name>
       <vts:KeyInfo>...</vts:KeyInfo>
     </Provider>
     <Issuer>
     <Name>Alice Book Center, Ltd.</Name>
       <vts:KeyInfo>...</vts:KeyInfo>
     </Issuer>

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Date: Wed, 21 Mar 2001 10:18:37 -0800 (PST)
From: Walt Houser <[email-masked]>
Subject: Comment on draft-ietf-trade-iotp2-req-00.txt
To: [email-masked], Walter Houser <[email-masked]>

The ID states:

   The following are out of scope for IOTP version 2:

   1. Legal or regulatory issues surrounding the
      implementation of the
      protocol or information systems using it.

   2. Design of an XML Messaging Layer.

wh: Should the ID point to BXXP? SOAP? XP?

   3. Design of XML Digitial Signatures.

wh: Should the ID point to XMLDS?
http://www.w3.org/TR/xmldsig-core/ 

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Date: Wed, 21 Mar 2001 13:07:33 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Minor edit of IOTP Payment API Draft
To: [email-masked]
Cc: [email-masked], [email-masked]

A version of the Payment API draft with minor editing changes is now
available at
<ftp://ftp.pothole.com/pub/ietf-trade/draft-ietf-trade-iotp-v1.0-papi-04.txt>.
This will probably be in the Internet-Draft directories next week.

Thanks,
Donald

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)

Date: Wed, 14 Mar 2001 14:58:03 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Draft Agenda for Minneaplis
To: [email-masked]
Cc: [email-masked]

Here is a draft agenda for the working group meeting at the 50th IETF
meetingin Minneapolis next week.  Comments welcome.

TRADE WG Draft Agenda (WEDNESDAY, March 21, 2001)

13:00	Agenday Bashing
13:10	Documents Status
13:20	IOTP/ECML Implementation Experience
13:35	ECML V2 Requirements
13:50	ECML V2 Specification
14:05	XML Voucher: Generic Voucher Language
14:35   IOTP V2 Requirements
14:50	Schedule Future Actions/Meetings
15:00	End

=====================================================================
  Donald E. Eastlake 3rd                      [email-masked]
  155 Beaver Street                                +1 508-634-2066(h)
  Milford, MA 01757 USA                            +1 508-261-5434(w)

Date: Wed, 14 Mar 2001 12:19:51 -0400
From: Ian Grigg <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
Sender: [email-masked]
To: Ko Fujimura <[email-masked]>
Cc: Rachel Willmer <[email-masked]>, [email-masked], [email-masked]
Reply-to: [email-masked]

Ko Fujimura wrote:
...
> > IMHO, there is no useful meaning to a Ricardian contract
> > "conforming" to a particular layout such as that described
> > for bonds.  Every bond is different, and there is no good
> > reason to make them all the same.  What will happen over
> > time is that new bonds will introduce new tags, and software
> > vendors will be encouraged to interpret these extra fields
> > according to their usefulness.
> 
> I agree. It is impossible to develop a specification that covers all types of
> vouchers in the world. I think that the goal of XML voucher is to cover 90%(?)
> of vouchers without introducing implementation difficulties.

OK.  Our goal with Ricardian Contracts is more adventurous,
to cover 100% of financial instruments :)  So far we've not
struck a case we can't say something about, although I admit
that futures are a bit tricky in Ricardo -- it's not obvious
how to deliver a tonne of pork bellies over the net.

As we are trying to cover everything, we do have sections
in there for different styles of instruments, and the format
allows the addition of others.  There are certain limitations
that may mitigate against some instruments, for example, the
format assumes that there is one central signatory, which is not
always the case.  But, it is close enough to the existing set
of contracts we work with, so it is put in the "future work"
basket of tasks.

[ Vouchers in the sense of tickets and loyalty we've never
really looked at closely... ]

> In the current voucher draft, <Title> is introduced for describing the name of the
> voucher (incl. currency).

<Title> is fine.  There is a need for several versions of the title,
there is at least a shortname and a full, legal title.  With currencies
there are often ISO TLAs and with shares there are often "symbols".

The shortname and the symbol are important variables for the program
to read.

You could do something like:

<Title shortname="Systemics" symbol="SYX">
  Systemics Incorporated
</Title>

> I'm not sure whether <type> is really needed, since other standards, e.g., IOTP, ECML,
> FTSC, X9.59, ..., does not has the property, and there is no modern currency that are
> not decimal.

The question revolves around whether you think that this field
forms part of the contract.  In my view, the type is a part of
the contract.

Other standards simply ignore the contract, and this is one
reason why they fail to grow into new areas.  For example, you'd
be hard pressed to find another standard that could differentiate
between a dollar issued by the Federal Reserve and a dollar issued
in the Euro markets - they pretty all much assume that the ISO has
it right and using the TLA "USD" will cover it.

You are right that there is no modern currency that is non-decimal,
and I can't even think of a bond or share or other instrument that
might be non-decimal.  So probably what I should do is make the
default for "type" be "decimal" and leave the question of other
conventions for whoever can find one.

> I understand that you introduced <decimal_power> to give the mapping information
> between the amount managed by the account (or SOX protocol) and the unit of the
> currency displayed. This is good idea since underlying system such as VTS does not
> have to care about the unit. Using this mapping information, a wallet system can
> transform it in a human readable form.

Yes, that's right.  The nature of the "cents" in any currency is
a decided part of the contract, but software works in cents whilst
humans work in dollars.  How this difficulty is resolved is very
important to a payment system.

> In the current voucher draft, I introduced <Value ratio="nnnn"/> syntax for similar
> purpose. Using this syntax, Ivan's dollar can be defined as follows:
> 
> <Voucher>
>   ...
>   <Promise>
>     <Title>Ivan's dollars</Title>
>     <Description>
>       Ivan's dollars are ...
>     </Description>
>     ...
>     <Value ratio="0.01" currency="USD" amount="1"/>
>     <Conditions>Only valid in Ivan's shops</Conditions>
>     ...
>   </Promise>
>   ...
> </Voucher>
> 
> I found currency_factor parameter in the Ricardian Contract. I think it is the same
> as the ratio attribute above. By the way, I think that either currency_factor or
> currency_decimal_power is enough for defining the mapping, am I right?

That's correct.  WebFunds has a routine that searches for each of them,
and uses the best available information.

> If so, why
> you choose currency_decimal_power? I think currency_factor is more flexible.

Currency_factor is in fact what we originally worked with, as it is
on the surface more flexible;  we can do something like .005 easily.

It turned out to be more of a nuisance than a feature.  Just as all
currencies are decimal, they are also all powers of ten.  By that, I
mean there was no *useful* scenario where we came across that required
a 200 cents in the dollar breakup.

[ I.e., in the beloved guilder economy, there are only 5c coins, they
abandoned the 1c a long time ago.  So, yes, if we wanted to issue
Ricardian guilders, we might want to set the factor to 0.05.  However,
it's all a matter of convenience, and there is more sense in setting
it to 0.01 and running with single cents as the software solves the
cost factor that caused the Dutch mint to drop the 1c coin. ]

And, the reason that sparked the change to decimal_power was that
programming with factors was hard.  Whilst accurate in the contract,
we had continual problems where the program code would trip up on
the fixed point calculations.  So, it became easier to set the power
as an integer 2, -2, whatever, and then write some support code that
produced the strings when necessary.  More code, but easier to control.

> Sorry for asking a lot. But, your experiences are really helpful for developping the
> specification.

No problem - as I say I intend to use your Voucher as the starting
point for the Ricardian conversion to XML.  The more work we get
done now, the easier it will be later :)

> I didn't introduce <fraction> in the above. Because, "$0.01" seems to be ok instead of
> "1c" in many cases, and the translation is quite easy in XML using the style sheet.

OK.  Another thing to be aware of is what it is you are defining.
In Ricardian Contracts, they define the "unit of contract" which
is always the unit that the software deals in.  I.e., cent or
milligram.  Then, the power/fraction/factor is used to define an
alternate representation for humans, called the "unit of account."

Getting this right is important - it needs to be part of the standard,
as software needs to agree and account for each and every cent.  Most
payment systems define both the unit of account and the unit of contract
as being equally important, and thus get themselves into all sorts of
knots trying to work out how to deal with them.

Also, bear in mind that I've moved the power into the previous section
so that *all* contracts are now subject to the units capability.  This
is because we've found that issuing shares or bonds with units of account
and distinct units of contract actually makes sense.  That is, millishares
is a "good idea" under some circumstances.

[ The best example of this is the shares in Warren Buffet's company,
Berkshire-Hathaway, which he deliberately never split as he wanted to
only keep large, important shareholders.  When they got to be worth 5
figures in dollars, even the papers had to stop quoting the share
price because the price columns only supported 4 figures.  Now, we
of course could break his game by issuing what I call Bufflets,
being microshares.  The unit of account would be one BH share, and
the unit of contract could be a millionth of that. ]
 
> > (for example ...)  One thing I'm unsure of is the appropriate form,
> > should it be tags everwhere or fields?  E.g., would the following
> > be more appropriate:
> >
> >  ...
> >  <currency name="ivan's dollars" type="decimal" power=2 fraction="c">
> >   Ivan's dollars are denominated in dollar units, with a fractional
> >   unit of contract of a cent.
> >  </currency>
> 
> That's fine. But I'm not sure whether the meaning should be written in natural
> language for monetary value, since its semantics is strictly defined using the
> attributes. But, non monetary value this syntax might be more appropriate...

Correct, this is one of the legal conundrums of a digital contract, what
happens when a defined field disagrees with a comment?

In my view, the fields dominate and the comments should be written to
explain the fields.  That's what I tell all the issuers, and in time I'd
hope that would become established as a custom (assuming my view is
valuable, that is).

What happens when a comment disagrees with a field is a gray area, and
I'm deliberately leaving this as a gray area.  That is, a judge would have
to rule.  So, an issuer would write a contract, and check the fields and
comments match.  And if they don't, then there are consequences.  But the
nature of those consequences are, IMHO, more properly determined in the
courts than in the technology.

[ For similar reasons, I will probably deliberately ban any "critical"
bit as exists in the FSML spec.  The effect of that is a legal nightmare,
only plausible in FSML because they are not really doing contracts, just
checks/cheques. ]

> <Voucher>
>   ...
>   <Promise>
>     <Title>Ivan's gold voucher (1mg)</Title>
>     <Description>
>       This voucher can be exchanged for 1mg of gold.
>     </Description>
>     ...
>     <Merchandise ratio="0.001" unit="g" amount="1">  [or ratio="1" unit="mg"]

Right, so here you need to make clear what both the minor unit
is and what the major unit is.  You will need a name for both of
them, and of course the ratio between them.  Something like:

<... ratio="0.001" major_unit="g" minor_unit="mg">

where I've used major and minor rather than my terms "unit of account"
and "unit of contract" to avoid assuming your intentions :)

>       Ivan's gold vouchers are denominated in gram of gold, with a fractional
>       unit of a milligram.
>     </Merchandise>
>     <Conditions>...</Conditions>
>     ...
>   </Promise>
>   ...
> </Voucher>
> 
> By the way, I'm not sure gold is currency or merchandise :-)

You may not be aware of the emerging gold economy, originated by the
e-gold company, with something like a tonne of gold in issuance as a
currency.  Digital gold is mostly a currency, sometimes a financial
instrument, but it is unlikely to make much impact as merchandise,
as digital gold doesn't have the allure and fashionability that
physical gold jewellry has.

-- 
iang

Date: Wed, 14 Mar 2001 20:48:43 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: [email-masked]
Cc: Rachel Willmer <[email-masked]>, [email-masked], [email-masked], [email-masked]

Ian Grigg wrote:
> ...
> > I think some of properties of the contract do not have to be interpreted
> > by the program and they are defined only for clarifying its legal meaning.
> > In case of bond, for example, bond_face, bond_currency, and
> > bond_maturity_date are needed to be processed especially when it is
> > redeemed. But, bond_issue_date and bond_total_issue_number seem to be
> > defined only for clarifying its legal meaning, am I right?
> 
> That's correct - the intention is to let a bond
> writer put in the fields he wants, and guide the important
> fields with conventions.  Obviously, things like face and
> maturity are needed so that calculations can be done.  The
> addition of the issue_date, etc, is simply there to complete
> the full set of data, not because a program can use them.
> 

Thank you very much for information. It's really helpful for considering the properties
of value (or voucher). 

> IMHO, there is no useful meaning to a Ricardian contract
> "conforming" to a particular layout such as that described
> for bonds.  Every bond is different, and there is no good
> reason to make them all the same.  What will happen over
> time is that new bonds will introduce new tags, and software
> vendors will be encouraged to interpret these extra fields
> according to their usefulness.

I agree. It is impossible to develop a specification that covers all types of 
vouchers in the world. I think that the goal of XML voucher is to cover 90%(?)
of vouchers without introducing implementation difficulties.

> 
> (Another thing to bear in mind is that the bonds area, whilst
> the original genesis of the Ricardo project, has not been
> used since the early days.  We've done most of the last 3
> years doing commodity currencies (precious metals) and are
> currently experimenting with shares and national currencies.)
> 
> > I think that we do not have to introduce specific tags for these
> > properties which are not interpreted by the software, since it is
> > sufficient to write them in a plain text in "one" XML element such as
> > <Contract>...</Contract>. I think it can be used as a criteria whether we
> > introduce as an element in XML voucher or not.
> > How do you think this approach?
> 
> Initially that would be fine - experience would guide us as to
> how to develop the inner parts.
> 
> One thing that happened with currency contracts that I didn't
> predict was that a currency issuer added a complete section
> called [conditions] and a lot of fields like conditions_backing,
> conditions_reserves, conditions_audit...  which all specified
> the terms of the contract in those particular areas.

It's good suggestion. I think we should introduce the <Conditions> element for 
that purpose.

> 
> Likewise, a new contract that is being worked on by an issuer
> has added a complete [definitions] section at the very beginning.
> If we were to translate his contract to an XML format, it would
> look like:
> 
> <contract>
>  <definitions>
>   <dollars>
>    [ivan's] dollars are ...
>   </dollars>
>   ...
>  </definitions>

In the current voucher draft, there is a <Description> element. I think the purpose
of <definitions> seems to be similar...

> 
>  <entity>
>   <shortname>...</shortname>
>  </entity>
> 
>  <issue>
>   ...
>  </issue>
> 
>  <currency>
>   <name>[ivan's] dollars</name>
>   <tla>USD</tla>
>   <type>decimal</type>
>   <decimal_power>2</decimal_power>
>   <fraction>c</fraction>
>  </currency>
>  ...
> </contract>
> 

In the current voucher draft, <Title> is introduced for describing the name of the
voucher (incl. currency).

I'm not sure whether <type> is really needed, since other standards, e.g., IOTP, ECML,
FTSC, X9.59, ..., does not has the property, and there is no modern currency that are 
not decimal.

I understand that you introduced <decimal_power> to give the mapping information 
between the amount managed by the account (or SOX protocol) and the unit of the 
currency displayed. This is good idea since underlying system such as VTS does not 
have to care about the unit. Using this mapping information, a wallet system can 
transform it in a human readable form.

In the current voucher draft, I introduced <Value ratio="nnnn"/> syntax for similar
purpose. Using this syntax, Ivan's dollar can be defined as follows:

<Voucher>
  ...
  <Promise>
    <Title>Ivan's dollars</Title>
    <Description>
      Ivan's dollars are ...
    </Description>
    ...
    <Value ratio="0.01" currency="USD" amount="1"/>
    <Conditions>Only valid in Ivan's shops</Conditions>
    ...
  </Promise>
  ...
</Voucher>

I found currency_factor parameter in the Ricardian Contract. I think it is the same 
as the ratio attribute above. By the way, I think that either currency_factor or 
currency_decimal_power is enough for defining the mapping, am I right? If so, why 
you choose currency_decimal_power? I think currency_factor is more flexible.
Sorry for asking a lot. But, your experiences are really helpful for developping the
specification.

I didn't introduce <fraction> in the above. Because, "$0.01" seems to be ok instead of 
"1c" in many cases, and the translation is quite easy in XML using the style sheet. 

> (for example ...)  One thing I'm unsure of is the appropriate form,
> should it be tags everwhere or fields?  E.g., would the following
> be more appropriate:
> 
>  ...
>  <currency name="ivan's dollars" type="decimal" power=2 fraction="c">
>   Ivan's dollars are denominated in dollar units, with a fractional
>   unit of contract of a cent.
>  </currency>

That's fine. But I'm not sure whether the meaning should be written in natural 
language for monetary value, since its semantics is strictly defined using the 
attributes. But, non monetary value this syntax might be more appropriate...

<Voucher>
  ...
  <Promise>
    <Title>Ivan's gold voucher (1mg)</Title>
    <Description>
      This voucher can be exchanged for 1mg of gold.
    </Description>
    ...
    <Merchandise ratio="0.001" unit="g" amount="1">  [or ratio="1" unit="mg"]
      Ivan's gold vouchers are denominated in gram of gold, with a fractional
      unit of a milligram.
    </Merchandise>
    <Conditions>...</Conditions>
    ...
  </Promise>
  ...
</Voucher>

By the way, I'm not sure gold is currency or merchandise :-)

Thank you!!

Ko

Date: Mon, 12 Mar 2001 18:18:45 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: [email-masked]
Cc: [email-masked], Rachel Willmer <[email-masked]>, [email-masked], [email-masked], [email-masked]

Hi Lynn,

Thank you very much for providing us a lot of X9.59 information.

I understand that the encoding rules of the spec will be helpful if XML Voucher 
have to define XML-encoding rules of a signed object...

But, the digital signature (or signed object) is used only in the delivery of 
Voucher Component or within the VTS-specific protocols that rewrite the ownership
of a voucher in the current XML Voucher processing model. In either cases, the 
XML-encoding rules of a signed object is outside scope of the XML Voucher 
specification (e.g., Encoding rules defined in XMLDSIG is another candidate).
This language design is one of major issues to be discussed in the next IETF 
meeting, though.

Thanks,

Ko
[email-masked] wrote:
> 
> there were/are two parts of FSML ....
> 
> 1) deterministic encoding rules for tagged grammers so that the signed object
> and the object having signature being verified will work in circumstances where
> the intermediate message have have totally mangled the original signed object.
> 
> 2) echeck
> 
> on the other hand, X9.59 standard was targeted at all account-based electronic
> payments; credit, debit, ATM, echeck, ACH, wire-transfers, internet,
> point-of-sale, wireless, etc.
> 
> The X9.59 standard calls for ASN.1 encoding.
> 
> A mapping of X9.59 to ISO8583 shows the original object being signed and then
> the fields from the original signed object being transmitted as ISO8583 fields
> (not in the format of the originally signed object) and then the originally
> signed object is reconstructed at the relying party and the signature verified.
> 
> An X9.59 object using  XML-ecoding rules could be implemented. However, in the
> case of the mapping example of X9.59 to ISO8583, the reconstruction of the
> signed object at the relying party has to be deterministic. As far as I know,
> FSML was the original tagged definition that specified deterministic encoding
> rules ... that would allow tagged-encoded objects to be reconstructed in a
> deterministic manner (therefor the FSML reference; not because of the echeck
> specification but because of its specifying deterministic encoding rules for
> tagged fields).

Date: Sat, 10 Mar 2001 10:26:38 -0800
From: Todd Boyle <[email-masked]>
Subject: RE: implementations of "XML Voucher: Generic Voucher Language" ?
To: [email-masked], Ko Fujimura <[email-masked]>
Cc: Rachel Willmer <[email-masked]>, [email-masked], [email-masked]
Reply-to: [email-masked]
Importance: Normal

I would like to point out the unmet need in the webledger space,
for any practical or standard technique by which a subscriber
might issue securitized payables obligations.

A webledger is a general accounting platform that runs in a
browser, and is only one of a large category of web apps in
which subscribers buy stuff or form accounts payable liabilities
of some sort.

At present, the banking industry (and a ravenous horde of billing
and payments solutions hardwired to the banking industry) are
pushing all kinds of **payment** solutions, i.e. crap that makes
you push every settlement thru a bank someplace.

There is considerable awareness in the webledger communities
that intercompany journal entries can be used to perform very
simple, well-understood balance sheet transfers to reassign
payables and receivables, from one party to another in your
ledger i.e. zero out all your payables or receivables and
send the information to a settlement agent.  This is obviously
an appealing idea to most small businesses if issues can be
put to rest regarding cost, trust, confidentiality and so forth.

Your role, as cryptologist is to show the webledger community
your least-common-denominator, absolutely common-sense software
algorithm and workflow for securitizing payables.  You need an
object that accepts rows of accounts payable ledger in some
standard such as OMG GL or emerging OMG AR/AP schemas, and
signs them somehow to be nonrepudiable by the issuer and prevents
double-spending.

The vision is that a recipient such as a settlement agent, will
receive a bundle of signed payables from a particular party,
such as MyWebledger:Subscriber234234 and there would be some
kind of protocol to contact MyWebledger over the intenret,
making MyWebledger, in effect, the host to prevent doublespending.
After a bit of round-trip verifying, the settlement agent would
have some measurable improvement in confidenc that the payable
was bonafide and hasn't been a complete fraud.   Yeah I know,
crackers might still find a hole.  Well, that's ok. This is
way better than sendnig GL rows in the clear over a VPN connection
or something-- all the solutions are nonstandard, today.

Another deliverable from this project might be that the
securitized payables message optionally, is encrypted to
be readable only by the intended addressee.  THe preferred
application however, is a free-for-all in which reputable
small businesses issue their own money and we all trade using
that money.  Obviously the large corps will collude to not
use this system but small businesses operate under different
incentives and cost pressures.

Finally, the receiver's object would extract, from the securitized
payables, the sets of accounts payable rows in ledger format
so that they can be managed and processed by the AR/AP system
of the receiver.

TOdd

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Ian Grigg
Sent: Friday, March 09, 2001 6:44 PM
To: Ko Fujimura
Cc: Rachel Willmer; [email-masked]; [email-masked]
Subject: Re: implementations of "XML Voucher: Generic Voucher Language"
?

<snip>
> By the way, I'm studying how to write your bond and currency defined
> in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
> in XML voucher.

Great!  Let me know when you're ready to issue :)

> I think some of properties of the contract do not have to be interpreted
> by the program and they are defined only for clarifying its legal meaning.
> In case of bond, for example, bond_face, bond_currency, and
> bond_maturity_date are needed to be processed especially when it is
> redeemed. But, bond_issue_date and bond_total_issue_number seem to be
> defined only for clarifying its legal meaning, am I right?

That's correct - the intention is to let a bond
writer put in the fields he wants, and guide the important
fields with conventions.  Obviously, things like face and
maturity are needed so that calculations can be done.  The
addition of the issue_date, etc, is simply there to complete
the full set of data, not because a program can use them.

IMHO, there is no useful meaning to a Ricardian contract
"conforming" to a particular layout such as that described
for bonds.  Every bond is different, and there is no good
reason to make them all the same.  What will happen over
time is that new bonds will introduce new tags, and software
vendors will be encouraged to interpret these extra fields
according to their usefulness.

(Another thing to bear in mind is that the bonds area, whilst
the original genesis of the Ricardo project, has not been
used since the early days.  We've done most of the last 3
years doing commodity currencies (precious metals) and are
currently experimenting with shares and national currencies.)

> I think that we do not have to introduce specific tags for these
> properties which are not interpreted by the software, since it is
> sufficient to write them in a plain text in "one" XML element such as
> <Contract>...</Contract>. I think it can be used as a criteria whether we
> introduce as an element in XML voucher or not.
> How do you think this approach?

Initially that would be fine - experience would guide us as to
how to develop the inner parts.

One thing that happened with currency contracts that I didn't
predict was that a currency issuer added a complete section
called [conditions] and a lot of fields like conditions_backing,
conditions_reserves, conditions_audit...  which all specified
the terms of the contract in those particular areas.

Likewise, a new contract that is being worked on by an issuer
has added a complete [definitions] section at the very beginning.
If we were to translate his contract to an XML format, it would
look like:

<contract>
 <definitions>
  <dollars>
   [ivan's] dollars are ...
  </dollars>
  ...
 </definitions>

 <entity>
  <shortname>...</shortname>
 </entity>

 <issue>
  ...
 </issue>

 <currency>
  <name>[ivan's] dollars</name>
  <tla>USD</tla>
  <type>decimal</type>
  <decimal_power>2</decimal_power>
  <fraction>c</fraction>
 </currency>
 ...
</contract>

(for example ...)  One thing I'm unsure of is the appropriate form,
should it be tags everwhere or fields?  E.g., would the following
be more appropriate:

 ...
 <currency name="ivan's dollars" type="decimal" power=2 fraction="c">
  Ivan's dollars are denominated in dollar units, with a fractional
  unit of contract of a cent.
 </currency>

--
iang

Date: Fri, 09 Mar 2001 22:44:28 -0400
From: Ian Grigg <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
Sender: [email-masked]
To: Ko Fujimura <[email-masked]>
Cc: Rachel Willmer <[email-masked]>, [email-masked], [email-masked]
Reply-to: [email-masked]

<snip>
> By the way, I'm studying how to write your bond and currency defined
> in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
> in XML voucher.

Great!  Let me know when you're ready to issue :)

> I think some of properties of the contract do not have to be interpreted
> by the program and they are defined only for clarifying its legal meaning.
> In case of bond, for example, bond_face, bond_currency, and
> bond_maturity_date are needed to be processed especially when it is
> redeemed. But, bond_issue_date and bond_total_issue_number seem to be
> defined only for clarifying its legal meaning, am I right?

That's correct - the intention is to let a bond
writer put in the fields he wants, and guide the important
fields with conventions.  Obviously, things like face and
maturity are needed so that calculations can be done.  The
addition of the issue_date, etc, is simply there to complete
the full set of data, not because a program can use them.

IMHO, there is no useful meaning to a Ricardian contract
"conforming" to a particular layout such as that described
for bonds.  Every bond is different, and there is no good
reason to make them all the same.  What will happen over
time is that new bonds will introduce new tags, and software
vendors will be encouraged to interpret these extra fields
according to their usefulness.

(Another thing to bear in mind is that the bonds area, whilst
the original genesis of the Ricardo project, has not been
used since the early days.  We've done most of the last 3
years doing commodity currencies (precious metals) and are
currently experimenting with shares and national currencies.)

> I think that we do not have to introduce specific tags for these
> properties which are not interpreted by the software, since it is
> sufficient to write them in a plain text in "one" XML element such as
> <Contract>...</Contract>. I think it can be used as a criteria whether we
> introduce as an element in XML voucher or not.
> How do you think this approach?

Initially that would be fine - experience would guide us as to
how to develop the inner parts.

One thing that happened with currency contracts that I didn't
predict was that a currency issuer added a complete section
called [conditions] and a lot of fields like conditions_backing,
conditions_reserves, conditions_audit...  which all specified
the terms of the contract in those particular areas.

Likewise, a new contract that is being worked on by an issuer
has added a complete [definitions] section at the very beginning.
If we were to translate his contract to an XML format, it would
look like:

<contract>
 <definitions>
  <dollars>
   [ivan's] dollars are ...
  </dollars>
  ...
 </definitions>

 <entity>
  <shortname>...</shortname>
 </entity>

 <issue>
  ...
 </issue>

 <currency>
  <name>[ivan's] dollars</name>
  <tla>USD</tla>
  <type>decimal</type>
  <decimal_power>2</decimal_power>
  <fraction>c</fraction>
 </currency>
 ...
</contract>

(for example ...)  One thing I'm unsure of is the appropriate form,
should it be tags everwhere or fields?  E.g., would the following
be more appropriate:

 ...
 <currency name="ivan's dollars" type="decimal" power=2 fraction="c">
  Ivan's dollars are denominated in dollar units, with a fractional
  unit of contract of a cent.
 </currency>

-- 
iang

Date: Fri, 09 Mar 2001 14:09:05 -0800
From: [email-masked]
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: Ko Fujimura <[email-masked]>
Cc: [email-masked], Rachel Willmer <[email-masked]>, [email-masked], [email-masked], [email-masked]

there were/are two parts of FSML ....

1) deterministic encoding rules for tagged grammers so that the signed object
and the object having signature being verified will work in circumstances where
the intermediate message have have totally mangled the original signed object.

2) echeck

on the other hand, X9.59 standard was targeted at all account-based electronic
payments; credit, debit, ATM, echeck, ACH, wire-transfers, internet,
point-of-sale, wireless, etc.

The X9.59 standard calls for ASN.1 encoding.

A mapping of X9.59 to ISO8583 shows the original object being signed and then
the fields from the original signed object being transmitted as ISO8583 fields
(not in the format of the originally signed object) and then the originally
signed object is reconstructed at the relying party and the signature verified.

An X9.59 object using  XML-ecoding rules could be implemented. However, in the
case of the mapping example of X9.59 to ISO8583, the reconstruction of the
signed object at the relying party has to be deterministic. As far as I know,
FSML was the original tagged definition that specified deterministic encoding
rules ... that would allow tagged-encoded objects to be reconstructed in a
deterministic manner (therefor the FSML reference; not because of the echeck
specification but because of its specifying deterministic encoding rules for
tagged fields).

X9 financial standards body web site:
http://www.x9.org/

ISO (international) financial standards body web site (US is the chair):
http://www.tc68.org/

misc. X9.59 standard description and discussions for all account-based
electronic payments (credit, debit, ATM, echeck, ACH, wire-transfers, internet,
point-of-sale, wireless, etc)
http://www.garlic.com~lynn/

description of the X9.59 standard example mapping to ISO8583
http://www.garlic.com/~lynn/8583flow.htm

X9.59 standard at the ANSI X9 online standards publication store:
http://webstore.ansi.org/ansidocstore/product.asp?sku=DSTU+X9%2E59%2D2000

Ko Fujimura <[email-masked]> on 03/09/2001 05:17:48 AM

To:   [email-masked]
cc:   Lynn Wheeler/CA/FDMS/FDC@FDC, Rachel Willmer <[email-masked]>,
      [email-masked], [email-masked]
Subject:  Re: implementations of "XML Voucher: Generic Voucher Language" ?

Thank you for your advice. But, the FSML v1.5 spec also seems to be
oriented to check processing.

By the way, I'm studying how to write your bond and currency defined
in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
in XML voucher.

I think some of properties of the contract do not have to be interpreted
by the program and they are defined only for clarifying its legal meaning.
In case of bond, for example, bond_face, bond_currency, and
bond_maturity_date are needed to be processed especially when it is
redeemed. But, bond_issue_date and bond_total_issue_number seem to be
defined only for clarifying its legal meaning, am I right?

I think that we do not have to introduce specific tags for these
properties which are not interpreted by the software, since it is
sufficient to write them in a plain text in "one" XML element such as
<Contract>...</Contract>. I think it can be used as a criteria whether we
introduce as an element in XML voucher or not.
How do you think this approach?

Regards,

Ko

Date: Fri, 09 Mar 2001 13:44:44 -0800
From: [email-masked]
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: Ko Fujimura <[email-masked]>
Cc: [email-masked], Rachel Willmer <[email-masked]>, [email-masked], [email-masked], [email-masked]

there were/are two parts of FSML ....

1) deterministic encoding rules for tagged grammers so that the signed object
and the object having signature being verified will work in circumstances where
the intermediate message have have totally mangled the original signed object.

2) echeck

on the other hand, X9.59 standard was targeted at all account-based electronic
payments; credit, debit, ATM, echeck, ACH, wire-transfers, internet,
point-of-sale, wireless, etc.

The X9.59 standard calls for ASN.1 encoding.

A mapping of X9.59 to ISO8583 shows the original object being signed and then
the fields from the original signed object being transmitted as ISO8583 fields
(not in the format of the originally signed object) and then the originally
signed object is reconstructed at the relying party and the signature verified.

An X9.59 object using  XML-ecoding rules could be implemented. However, in the
case of the mapping example of X9.59 to ISO8583, the reconstruction of the
signed object at the relying party has to be deterministic. As far as I know,
FSML was the original tagged definition that specified deterministic encoding
rules ... that would allow tagged-encoded objects to be reconstructed in a
deterministic manner (therefor the FSML reference; not because of the echeck
specification but because of its specifying deterministic encoding rules for
tagged fields).

X9 financial standards body web site:
http://www.x9.org/

ISO (international) financial standards body web site (US is the chair):
http://www.tc68.org/

misc. X9.59 standard description and discussions for all account-based
electronic payments (credit, debit, ATM, echeck, ACH, wire-transfers, internet,
point-of-sale, wireless, etc)
http://www.garlic.com~lynn/

description of the X9.59 standard example mapping to ISO8583
http://www.garlic.com/~lynn/8583flow.htm

X9.59 standard at the ANSI X9 online standards publication store:
http://webstore.ansi.org/ansidocstore/product.asp?sku=DSTU+X9%2E59%2D2000

Ko Fujimura <[email-masked]> on 03/09/2001 05:17:48 AM

To:   [email-masked]
cc:   Lynn Wheeler/CA/FDMS/FDC@FDC, Rachel Willmer <[email-masked]>,
      [email-masked], [email-masked]
Subject:  Re: implementations of "XML Voucher: Generic Voucher Language" ?

Thank you for your advice. But, the FSML v1.5 spec also seems to be
oriented to check processing.

By the way, I'm studying how to write your bond and currency defined
in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
in XML voucher.

I think some of properties of the contract do not have to be interpreted
by the program and they are defined only for clarifying its legal meaning.
In case of bond, for example, bond_face, bond_currency, and
bond_maturity_date are needed to be processed especially when it is
redeemed. But, bond_issue_date and bond_total_issue_number seem to be
defined only for clarifying its legal meaning, am I right?

I think that we do not have to introduce specific tags for these
properties which are not interpreted by the software, since it is
sufficient to write them in a plain text in "one" XML element such as
<Contract>...</Contract>. I think it can be used as a criteria whether we
introduce as an element in XML voucher or not.
How do you think this approach?

Regards,

Ko

Date: Fri, 09 Mar 2001 09:15:00 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: IOTPV2: XML messaging
To: Ko Fujimura <[email-masked]>
Cc: [email-masked]

I'd like to know also.  :-) I think ebXML is the most likely candidate
right now.  The working group consensus has consistently been in favor
of picking a messaging protocol specified elsewhere rather than
rolling our own.  Hopefully the timing will work out so that we can
pick what will become the dominant messaging protocol...

Thanks,
Donald

From:  Ko Fujimura <[email-masked]>
Date:  Fri, 09 Mar 2001 18:02:13 +0900
To:  [email-masked]
Message-id:  <[email-masked]>

>In <http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp2-req-00.txt>:
>
>> INTERNET-DRAFT            IOTP v2 Requirements             February 2001
>> 
>> 
>> 1. Introduction
>> 
>>    Verion 2 of the Internet Open Trading Protocol (IOTP) will extend the
>>    interoperable framework for Internet commerce capabilities of Version
>>    1 [RFC 2801] as described in Section 3 below.  In addition, it will
>>    replace the ad hoc XML messaging and digitial signature [RFC 2802]
>>    parts of IOTP v1 with standards based mechanisms.
>
>Which XML messaging protocols will be used for replacing current XML messaging?
>Do you assume that ebXML TR/P for underlying protocol of IOTP version 2?
>I would like to know the direction of the language design. 
>
>Thanks,
>
>Ko Fujimura, NTT

Date: Fri, 09 Mar 2001 22:17:48 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: [email-masked]
Cc: [email-masked], Rachel Willmer <[email-masked]>, [email-masked], [email-masked]

Ian Grigg wrote:
> 
> [email-masked] wrote:
> ...
> >
> > for some fsml related information
> >
> > http://www.echeck.org/
> 
> I printed out the 1.5.  The document formatting rules look like a
> useful starting point for XML contracts (including the Voucher
> work).
> 
> The rest of the document seems to be oriented to check processing.
> Even though it claims that it might be used for generic documents,
> I doubt it, as there are too many assumptions about how checks work
> built into it, as well as lots of protocol stuff.

Thank you for your advice. But, the FSML v1.5 spec also seems to be 
oriented to check processing.

By the way, I'm studying how to write your bond and currency defined 
in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
in XML voucher.

I think some of properties of the contract do not have to be interpreted 
by the program and they are defined only for clarifying its legal meaning. 
In case of bond, for example, bond_face, bond_currency, and 
bond_maturity_date are needed to be processed especially when it is 
redeemed. But, bond_issue_date and bond_total_issue_number seem to be 
defined only for clarifying its legal meaning, am I right?

I think that we do not have to introduce specific tags for these 
properties which are not interpreted by the software, since it is 
sufficient to write them in a plain text in "one" XML element such as 
<Contract>...</Contract>. I think it can be used as a criteria whether we 
introduce as an element in XML voucher or not.
How do you think this approach?

Regards,

Ko

Date: Fri, 09 Mar 2001 18:02:13 +0900
From: Ko Fujimura <[email-masked]>
Subject: IOTPV2: XML messaging
To: [email-masked]

In <http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp2-req-00.txt>:

> INTERNET-DRAFT            IOTP v2 Requirements             February 2001
> 
> 
> 1. Introduction
> 
>    Verion 2 of the Internet Open Trading Protocol (IOTP) will extend the
>    interoperable framework for Internet commerce capabilities of Version
>    1 [RFC 2801] as described in Section 3 below.  In addition, it will
>    replace the ad hoc XML messaging and digitial signature [RFC 2802]
>    parts of IOTP v1 with standards based mechanisms.

Which XML messaging protocols will be used for replacing current XML messaging?
Do you assume that ebXML TR/P for underlying protocol of IOTP version 2?
I would like to know the direction of the language design. 

Thanks,

Ko Fujimura, NTT

Date: Wed, 07 Mar 2001 11:53:39 -0800
From: "Lewis, Tony" <[email-masked]>
Subject: RE: ECML: clear field definitions appreciated
To: [email-masked]

On Wednesday, March 07, 2001 9:14 AM, Mia Lahteenmaki wrote:

> In another words, the protocol names on the list must 
> unambiquously reference to one protocol. 

I agree wholeheartedly.
 
> Like 'set' is for SET protocol and in the ECML spec a 
> reference to the SET specs can be given. 
> Both parties know exactly what it means. Merchant can 
> create a SET wakeup to start the process. 

Perhaps it would be better to use something like
http://www.setco.org/set/v1.0 instead of "set".
 
> Now there exist "protocol names" already in the list 
> that do not have unambiguous meaning, like "simcard" 
> and "phoneid". These values do not define any one protocol 
> or at least we have no reference to such protocols. 
> So if merchant receives these values from the wallet 
> what he should do next?  

We should get rid of the names that don't correlate to a specific protocol.
_________________________________________________________________
Tony Lewis ([email-masked])
Chief Systems Architect, Internet Commerce
Visa International Service Association

Date: Wed, 07 Mar 2001 19:14:05 +0200
From: [email-masked]
Subject: RE:RE: ECML: clear field definitions appreciated
To: [email-masked], [email-masked]

> On Tuesday 06. March 2001 18:51, Lewis, Tony wrote: 
> 
> On Tuesday, March 06, 2001 3:11 AM, Mia Lahteenmaki wrote:
> 
> > The fields that in my opinion do not fullfil the above 
> requirements at 
> > all are 1) Ecomm_Payment_Card_Protocol (some values still unclear, 
> > although Donald Eastlake has been admirably trying to get 
> some answers), 
> 
> I agree that the fields need to be clearly defined. However, on this
> particular field, the specification to allow new values for 
> the field to be
> created easily. When new payment protocols are created, it 
> should be easy to
> add the protocol so that the creators feel comfortable using 
> IOTP. Perhaps
> it is just a matter of creating a registrar for the values.
> _________________________________________________________________
> Tony Lewis ([email-masked])
> Chief Systems Architect, Internet Commerce
> Visa International Service Association

Good point. I was being unclear. 
I agree Tony that adding new protocols to the 
list should be easy. My intention on the particular 
field was that when introducing a new item value for 
the protocol field we can give 
a)a pointer to the protocol spec or 
b) say that this is a proprietary protocol that 
is not public and it is used by xxx systems. 

In another words, the protocol names on the list must 
unambiquously reference to one protocol. 

Like 'set' is for SET protocol and in the ECML spec a 
reference to the SET specs can be given. 
Both parties know exactly what it means. Merchant can 
create a SET wakeup to start the process. 

Now there exist "protocol names" already in the list 
that do not have unambiguous meaning, like "simcard" 
and "phoneid". These values do not define any one protocol 
or at least we have no reference to such protocols. 
So if merchant receives these values from the wallet 
what he should do next?  

I assume that the underlying assumption about the mobile
world has been that the customer is able to shop only in 
a closed operator network where both the customer and 
the merchant necessarily have contracts with the operator. 
Inside this network the meaning of these protocol names 
would then be unabiquously defined and everything would 
work fine.
With mobile access to internet e.g., via WAP this is not 
however true. 

Best Regards,
Mia    

Date: Tue, 06 Mar 2001 08:50:43 -0800
From: "Lewis, Tony" <[email-masked]>
Subject: RE: ECML: clear field definitions appreciated
To: [email-masked]

On Tuesday, March 06, 2001 3:11 AM, Mia Lahteenmaki wrote:

> The fields that in my opinion do not fullfil the above requirements at 
> all are 1) Ecomm_Payment_Card_Protocol (some values still unclear, 
> although Donald Eastlake has been admirably trying to get some answers), 

I agree that the fields need to be clearly defined. However, on this
particular field, the specification to allow new values for the field to be
created easily. When new payment protocols are created, it should be easy to
add the protocol so that the creators feel comfortable using IOTP. Perhaps
it is just a matter of creating a registrar for the values.
_________________________________________________________________
Tony Lewis ([email-masked])
Chief Systems Architect, Internet Commerce
Visa International Service Association

Date: Tue, 06 Mar 2001 13:11:14 +0200
From: [email-masked]
Subject: ECML: clear field definitions appreciated
To: [email-masked]

Hi,
Old ECML fields were self-explanatory, so they could be explained with a few
foot notes but the new fields require clear definitions, or otherwise the
spec looses its main aim. 

One requirement for the specification work could be that 
a)fields are well-defined in detail for any party to use or 
b)it is explicitly said that this is proprietary field and you can use it as
you like. So if we want to support proprietary work, that's also fine, but
let's do it openly then so that the whole point of spec is not lost.

The fields that in my opinion do not fullfil the above requirements at all
are
1) Ecomm_Payment_Card_Protocol (some values still unclear, although Donald
Eastlake has been admirably trying to get some answers), and 

2) Ecomm_Transaction_Signature field (Ecomm_Transaction_Signature) where the
footnote tells that 
"(31) The signature of the encoded certificate.  This is usually a hidden
field."
Huh? What does this mean?

3) Ones that are promised to be defined later :-)  We will hear about these
more soon I hope.

Best Regards
Mia Lahteenmaki

Date: Tue, 06 Mar 2001 19:18:05 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Contracts and XML Voucher
To: [email-masked]
Cc: [email-masked]

Hi Ian,

Thank you for your comments:

Ian Grigg wrote:
> 
> Ko Fujimura wrote:
...
> > Through the development of early version of this system, we learned importance
> > of standardization of "contract" or "value description language" that describes
> > what/how values/rights are traded between the trading partners.
> 
> Do you mean the term "contract" in its legal sense, or in the
> information sense?  That is, the law of contract applies, or,
> that the "contract" or interface is specified as per programming
> needs?

I used it in the legal sense, but rather weak meaning. In other words,
It can be used it legally if the issuer provides enough information within the 
Promise element. Using the XML-naming facility, any application-specific 
properties can be extended in the Merchandise element. For example:

<Promise>
  ...
  <Merchandise xmlns="http://www.example.org/bond.txt">
     <Bond identitiy="..." issueDate="..." .../>
  </Merchandise>
<Promise>

(I'm not sure tag name "Merchandise" is appropriate.) 

But, strictly speaking, it might be a fragment of a contract, since issuer's 
signature is attached externally as you pointed out.

> 
> If you mean the term in the sense of law and negotiating parties,
> I would wonder how the Voucher could stand up to a dispute?  In
> the Ricardian concept, we insist that the contract be readable
> by humans, linked to the asset in question, signed by the Issuer,

Right. Readability is an important issue of XML. Plain text is a good approach
in this sense. But, it was also discussed in the XMLDSIG WG and summary of the 
discussion is incorporated in Section 8 of the current XMLDSIG spec:
<http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/#sec-Security>.

> and some form of open PKI in operation that provides evidence of
> intention, and other devices to maintain the consistency of the
> contract under a wide degree of circumstances.

My basic idea is to leave this issue to other specification, i.e., XMLDSIG,
since it seems to be a general issue of XMLDSIG.
We haven't specified how <vts:KeyInfo> is used in the current draft.
But, one idea is to adopt/refer <KeyInfo> defined in the XMLDSIG spec as it is. 

Recently, the spec of KeyInfo have been discussed actively in the XMLDSIG WG.
(See archive below:)

"Donald E. Eastlake 3rd" wrote in: 
<http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0073.html>
 
> I think the various sides of this issue
> <http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0039.html>
> have been well argued and that it is unlikely there will be much
> furhter change in opinion.  The consensus of the Working Group is for
> option 2 and we will proceed on the basis of that choice.  This also
> means including clearer criterion as to when elements other than those
> we have defined can be included within the {X509|PGP|SPKI}Data
> element.
> 
> I suggest the text in the editors draft at
> <http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-KeyInfo>
> be changed to be the HTML appended below.

Regards, 

Ko

Date: Mon, 05 Mar 2001 11:22:25 -0800
From: [email-masked]
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: [email-masked]
Cc: Ko Fujimura <[email-masked]>, Rachel Willmer <[email-masked]>, [email-masked], [email-masked]

as an aside, X9.59 financial standard that recently passed (electronic standard
for all retail payments) also incorporates the message digest of the purchase
order (or contract) in the body of the payment message.

as specified in the standard, the payment message encoding format is ASN.1 ...
however the appendix includes an example in FSML (financial standards markup
language ... precursor to much of the XML financial related specifications).

financial standards bodys are at

http://www.x9.org/
http://www.tc68.org/

for some fsml related information

http://www.echeck.org/

misc. x9.59 information

http://www.garlic.com/~lynn/

Ian Grigg <[email-masked]> on 03/05/2001 08:59:35 AM

Please respond to [email-masked]

To:   Ko Fujimura <[email-masked]>
cc:   Rachel Willmer <[email-masked]>, [email-masked],
      [email-masked]
Subject:  Re: implementations of "XML Voucher: Generic Voucher Language" ?

That's an interesting point.  In our system, the identity of the
contract is provided by a canonical message digest (calculated
over the readable contract) which is used as the identifier in
payments.  There is nothing in the SOX protocol that limits the
usage to that digest, and nothing in the Ricardian Contract that
says which protocol to use (and indeed, it is possible to plugin
a separate payment system into WebFunds, and use Ricardian Contracts),
it's mostly an implementation issue.

However, there is ample flexibility in the contract format, and
indeed, any similar format like your XML Voucher one, to add a
limitation of protocol.  That might become interesting in the
future as we are adding different transaction types to WebFunds
as a background task, and are using Ricardian Contracts in areas
that don't involve SOX directly.

--
iang

Date: Mon, 05 Mar 2001 12:59:35 -0400
From: Ian Grigg <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
Sender: [email-masked]
To: Ko Fujimura <[email-masked]>
Cc: Rachel Willmer <[email-masked]>, [email-masked], [email-masked]
Reply-to: [email-masked]

Ko Fujimura wrote:
> 
> Hi Rachel,
> 
> > Are you familiar with Systemics Ricardo system, which uses Ricardian
> > contracts to implement the concept that you call "vouchers"?
> >
> > <http://www.systemics.com>
> >
> > This system has been around for about 5 years and has been used in the
> > fields of currency, stocks and bonds. The use of "Ricardian contracts" or
> > "vouchers" is a critical part of the architecture.
> 
> Yes, I read his paper presented at FC'00 about one year ago. I like the design of
> the Ricardo system since it provides both flexibility and simplicity using modular
> software components.

Thanks!  The paper is at http://www.iang.org/papers/ and the
software mentioned is at http://www.webfunds.org/ .

> > We're in the process of integrating their Ricardo system into our
> > CashBox(tm) system, and I'm interested in knowing about any other companies
> > who may be implementing other payment systems based on these concepts, so
> > please do let me know when others do implement.
> 
> Our FlexTicket system is a smartcard-based value/rights circulation system and
> provides transferability and offline capability. There are more information on
> the protocols presented at CARDIS 2000.
> <http://info.isl.ntt.co.jp/flexticket/papers/>

I had a look through this yesterday and put some information
on the proposal, as an 'alternate' to our Ricardian contract
concept, up on the webfunds site:

    http://www.webfunds.org/guide/ricardian.html

What is very interesting to us is that we may be able to use
your formats for the Ricardian Contract in XML -- it is a future
task for us to convert to the XML world for all the normal
reasons.

(The comparison come across as a little unfavourable because
it tries to measure the Voucher against our own internal
contracting requirements, which are accepted as being quite
fierce!).

> Through the development of early version of this system, we learned importance
> of standardization of "contract" or "value description language" that describes
> what/how values/rights are traded between the trading partners.

Do you mean the term "contract" in its legal sense, or in the
information sense?  That is, the law of contract applies, or,
that the "contract" or interface is specified as per programming
needs?

If you mean the term in the sense of law and negotiating parties,
I would wonder how the Voucher could stand up to a dispute?  In
the Ricardian concept, we insist that the contract be readable
by humans, linked to the asset in question, signed by the Issuer,
and some form of open PKI in operation that provides evidence of
intention, and other devices to maintain the consistency of the
contract under a wide degree of circumstances.

(Although, we are mostly concerned with English common law contracts,
I haven't got a view as to how they stand up in other legal domains.)

> We are going to implement XML voucher as soon as it completed.

You may find the framework in WebFunds to be of interest.  There,
we have a contract browser that reads in the contracts, verifies
the signatures, and can display the text.  There is also a nice
contract signing wizard that takes you through the process of
doing your own contract.  It's early days yet, this is really an
automation tool rather than a replacement for the complicated
process of underwriting;  it doesn't give you enough help in order
to write your own contract, if just automates some of the tasks
that are bothersome.

> By the way, I think that generic value transfer protocols like the Ricardo' SOX
> protocols are exciting and important. But, I think it is difficult to cover all
> application area using one universal value transfer protocol. We therefore think
> that "contract" should contain a parameter that specify which the protocols
> (or "VTS provider" in XML Voucher) are used. I think it will help to develop
> generic digital wallet like your CashBox(tm).

That's an interesting point.  In our system, the identity of the
contract is provided by a canonical message digest (calculated
over the readable contract) which is used as the identifier in
payments.  There is nothing in the SOX protocol that limits the
usage to that digest, and nothing in the Ricardian Contract that
says which protocol to use (and indeed, it is possible to plugin
a separate payment system into WebFunds, and use Ricardian Contracts),
it's mostly an implementation issue.

However, there is ample flexibility in the contract format, and 
indeed, any similar format like your XML Voucher one, to add a
limitation of protocol.  That might become interesting in the
future as we are adding different transaction types to WebFunds
as a background task, and are using Ricardian Contracts in areas
that don't involve SOX directly.

-- 
iang

Date: Mon, 05 Mar 2001 15:27:24 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Instance and Definition of Voucher
To: Raghuram Rajah <[email-masked]>
Cc: [email-masked]

Raghuram Rajah wrote:

> A few thoughts about the Voucher definition.
> 
> 4. Component Structure - Defining the components associated with the voucher
> itself (like ValidPeriod), seem to constraint the potential of the voucher.
> Wouldn't it be better to define a overall framework that can support an
> ability to define meta-data and behaviour. We can standardize some meta-data
> like ValidPeriod, but the issuer should be able to define more.
> 
> Also, in one of Ko's earlier presentation (when discussing requirements), I
> saw a division of the voucher into two parts - Definition and the actual
> voucher. I felt the approach was admirable, for it provided a mechanism to
> define the shape of the voucher and the data as two seperate entities.Making
> a distinction between the core voucher and the meta-description information,
> helps a lot when the voucher has to be stored on a limited device like the
> smart card.
> 
> We had built a "voucher" (we called it coupon) system for the smart card.
> Let me go over that design philosophy, which are in line with one of Ko's
> earlier presentation. Thus, I would think the voucher is defined by two
> entities,
> 
> - Voucher Definition. Defines the shape and behaviour of the voucher.
> - Voucher Instance. The core data of the voucher based on the defintion.

In the XML voucher document (Page 2), there is a description:

     Note: This document uses a "voucher" as an "instance of voucher"
     whose meaning is defined by Voucher Component. In other words,
     multiple vouchers can be issued and managed by the VTS using the
     same Voucher Component.

It might not be clear enough. But, I use "Voucher Component" as the meaning 
of "Voucher Definition". So, the current document already assumes the 
separation of the Definition and Instance. But, values of properties 
are also specified in the Definition if the value is fixed across the same 
type of the voucher as you pointed out.

The Voucher Component is used to make consensus between trading partners 
what/how the voucher are traded. In this sense, I think that the contents 
of voucher should be exchanged between the trading partners before actual 
"delivery of voucher instance" or "rewrite of the ownership". In this sense,
it should be specific enough so that trading partners can agree the item to 
be traded. I use Voucher *Component* since it might be used in offer exchange 
or other trading transactions.

The "instance of voucher", on the other hand, can be implemented as the 
identifier (or hash) of the Voucher Component if the Voucher Component is 
specific enough. This approach is key to achieving implementation flexibility 
and efficiency. 

By the way, the data structure of the "instance of voucher" is completely left 
to the VTS implementation. It may includes some VTS-specific parameters needed 
for preventing duplicate redemption, etc.

> 
> The Voucher Definition defines the genre of coupon,
> 
> eg. x% off any purchase greater than $y between m1/d1/y1 and m2/d2/y2 - Defn
> A
>     $x off purchase at YYY Store - Defn B
> 
> The Voucher Instance on the other hand is the actual coupon that specifies
> the values of variables,
> 
> eg. Coupon Defn A; x=5; y=25; m1/d1/y1 = 11/2/2000; m2/d2/y2 = 12/25/2000
>     Coupon Defn B; x=25; YYY = Sears
> 

Both of these Definition and Instance are considered as Voucher Component in my 
definition. But, I think it is possible to introduce such a layered definition 
within Voucher Component. It introduces, however, more implementation complexity. 
So, I didn't include this facility in the first version of the draft specification.

Thanks.

Ko

Date: Mon, 05 Mar 2001 11:05:38 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: Rachel Willmer <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

Hi Rachel,

> Are you familiar with Systemics Ricardo system, which uses Ricardian
> contracts to implement the concept that you call "vouchers"?
>
> <http://www.systemics.com>
>
> This system has been around for about 5 years and has been used in the
> fields of currency, stocks and bonds. The use of "Ricardian contracts" or
> "vouchers" is a critical part of the architecture.

Yes, I read his paper presented at FC'00 about one year ago. I like the design of 
the Ricardo system since it provides both flexibility and simplicity using modular 
software components.

>
> I've copied this mail to Ian Grigg from Systemics <[email-masked]>,
> because I think it may be worth you both engaging in some dialogue.

Thank you.

>
> We're in the process of integrating their Ricardo system into our
> CashBox(tm) system, and I'm interested in knowing about any other companies
> who may be implementing other payment systems based on these concepts, so
> please do let me know when others do implement.

Our FlexTicket system is a smartcard-based value/rights circulation system and 
provides transferability and offline capability. There are more information on 
the protocols presented at CARDIS 2000. 
<http://info.isl.ntt.co.jp/flexticket/papers/>

Through the development of early version of this system, we learned importance 
of standardization of "contract" or "value description language" that describes 
what/how values/rights are traded between the trading partners. 
We are going to implement XML voucher as soon as it completed.

By the way, I think that generic value transfer protocols like the Ricardo' SOX 
protocols are exciting and important. But, I think it is difficult to cover all 
application area using one universal value transfer protocol. We therefore think 
that "contract" should contain a parameter that specify which the protocols 
(or "VTS provider" in XML Voucher) are used. I think it will help to develop 
generic digital wallet like your CashBox(tm).

Regards,

Ko
----------------------------------------------------------
Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-2241
Email: [email-masked]

Date: Fri, 02 Mar 2001 10:20:47 -0500
From: Raghuram Rajah <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-trade-voucher-lang-00.txt
To: [email-masked]

Hi,

A few thoughts about the Voucher definition.

4. Component Structure - Defining the components associated with the voucher 
itself (like ValidPeriod), seem to constraint the potential of the voucher. 
Wouldn't it be better to define a overall framework that can support an 
ability to define meta-data and behaviour. We can standardize some meta-data 
like ValidPeriod, but the issuer should be able to define more.

Also, in one of Ko's earlier presentation (when discussing requirements), I 
saw a division of the voucher into two parts - Definition and the actual 
voucher. I felt the approach was admirable, for it provided a mechanism to 
define the shape of the voucher and the data as two seperate entities.Making 
a distinction between the core voucher and the meta-description information, 
helps a lot when the voucher has to be stored on a limited device like the 
smart card.

We had built a "voucher" (we called it coupon) system for the smart card. 
Let me go over that design philosophy, which are in line with one of Ko's 
earlier presentation. Thus, I would think the voucher is defined by two 
entities,

- Voucher Definition. Defines the shape and behaviour of the voucher.
- Voucher Instance. The core data of the voucher based on the defintion.

The Voucher Definition defines the genre of coupon,

eg. x% off any purchase greater than $y between m1/d1/y1 and m2/d2/y2 - Defn 
A
    $x off purchase at YYY Store - Defn B

The Voucher Instance on the other hand is the actual coupon that specifies 
the values of variables,

eg. Coupon Defn A; x=5; y=25; m1/d1/y1 = 11/2/2000; m2/d2/y2 = 12/25/2000
    Coupon Defn B; x=25; YYY = Sears

One of our initial XML DTDs looked like this,

CouponInstance DTD
~~~~~~~~~~~~~~~~~~

<!DOCTYPE BlueCoupon [

  <!ELEMENT BlueCoupon (CouponDefinition, Value, Constraint*,
			Signature?, CouponData?,
			Keyword?)>
  <!ATTLIST BlueCoupon ID #REQUIRED>    <!-- Numeric, upto 13 digits -->

  <!ELEMENT CouponDefinition (CouponProviderID, CouponDefinitionID)>
  <!ELEMENT CouponProviderID (#PCDATA)>  <!-- Numeric, upto 5 digits -->
  <!ELEMENT CouponDefinitionID (#PCDATA) <!-- Numeric, upto 8 digits -->

  <!ELEMENT Value (#PCDATA)             <!-- Numeric, 32-bit unsigned -->

  <!ELEMENT Constraint (#PCDATA)>       <!-- data type specified in the 
Definition -->
  <!ATTLIST Constraint ID #REQUIRED>    <!-- Numeric 16-bit, Unique, should 
be present in Defn-->

  <!ELEMENT Signature (#PCDATA)         <!-- doesn't include keywords -->
  <!ELEMENT CouponData (#PCDATA)	<!-- user data, optional -->

  <!ELEMENT Keyword ANY>                <!-- defined by the Provider -->

]>

CouponDefinition DTD
~~~~~~~~~~~~~~~~~~~~

<!DOCTYPE BlueCouponDefinition [

  <!ELEMENT BlueCouponDefinition (CouponType, ConstraintDefn*,
                                  Resource?, SignatureProperties)>
  <!ATTLIST BlueCouponDefinition ID #REQUIRED>      <!-- Numeric, upto 8 
digits -->

  <!ELEMENT CouponType (Stateful?, ValueType)>
  <!ELEMENT Stateful EMPTY>
  <!ELEMENT ValueType (#PCDATA)> <!-- Type to be understood by the using 
system -->

  <!ELEMENT ConstraintDefn (Name?, Description?, Type, Behaviour)>
  <!ATTLIST ID #REQUIRED>        <!-- This is used to specify values in the 
instance,
                                      and should be sequential for 
bluecoupon -->
  <!ELEMENT Name (#PCDATA)>
  <!ELEMENT Description (#PCDATA)>
  <!ELEMENT Type (Scalar | Currency | Floating | Date | String | Int32 | 
Int16)>
  <!ELEMENT Behaviour (Equal | NotEqual | Greater | GreaterEqual | Lesser | 
LesserEqual)

  <!ELEMENT Resource (Promise?, Icon?)>
  <!ELEMENT Promise (#PCDATA)>   <!-- url for the textual description of the 
promise -->
  <!ELEMENT Icon (#PCDATA)>      <!-- url for the icon associated with the 
promise -->

  <!ELEMENT SignatureProperties (SignatureMethod)> <!-- we might have to 
include the
                                                       encryption key too 
here, lets see -->
  <!ELEMENT SignatureMethod (#PCDATA)> <!-- method understood by using 
system
                                            like SHA-1 or MD5 -->

]>

EXAMPLE
~~~~~~~

<BlueCouponDefinition ID=78698563>
<CouponType>
  <ValueType>Percent</ValueType>
</CouponType>

<ConstraintDefn ID=1>
  <Name> MinPurchaseInCurrency </Name>
  <Type> Currency </Type>
</ConstraintDefn>

<ConstraintDefn ID=2>
  <Name> ValidityEndDate </Name>
  <Type> Date </Type>
</ConstraintDefn>

<ConstraintDefn ID=3>
  <Name> Vendor </Name>
  <Type> Numeric-5 </Type>
</ConstraintDefn>

<SignatureProperties>
  <SignatureMethod>SHA-1</SignatureMethod>
</SignatureProperties>
</BlueCouponDefinition>

<BlueCoupon ID=36948935845189>
<CouponDefinition>
  <CouponProviderID>12345</CouponProviderID>
  <CouponDefinitionID>78698563</CouponDefinitionID>
</CouponDefinition>

<Value>20</Value>

<Constraint ID=1>50</Constraint>
<Constraint ID=2>12/20/2000</Constraint>
<Constraint ID=3>45282</Constraint>

<Signature>94675745756756772</Signature>

<Keyword>
  <Category>General Merchandise
</Keyword>
</BlueCoupon>

Common Keywords/Constraints
~~~~~~~~~~~

Keywords
  - Category
  - Zipcode
  - City

Constraints
  - Product
  - Vendor
  - ValidityStartDate
  - ValidityEndDate
  - MaxUsageCount
  - Circulation
  - MinPurchaseCurrency
  - MaxPurchaseCurrency
  - MinPurchaseQty
  - MaxPurchaseQty
  - MaxCouponValue

>From: [email-masked]
>Reply-To: [email-masked]
>To: IETF-Announce: ;
>CC: [email-masked]
>Subject: I-D ACTION:draft-ietf-trade-voucher-lang-00.txt
>Date: Thu, 22 Feb 2001 07:04:37 -0500
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Internet Open Trading Protocol Working 
>Group of the IETF.
>
>	Title		: XML Voucher: Generic Voucher Language
>	Author(s)	: K. Fujimura
>	Filename	: draft-ietf-trade-voucher-lang-00.txt
>	Pages		: 8
>	Date		: 21-Feb-01
>
>This document specifies rules for defining voucher properties in
>XML syntax. A voucher is a logical entity that represents a right
>to claim goods or services. A voucher can be used to transfer a
>wide-range of electronic-values, including coupons, tickets,
>loyalty points, and gift certificates, which are often necessary to
>process in the course of payment and/or delivery transactions.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-lang-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-trade-voucher-lang-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-trade-voucher-lang-00.txt".
>
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
><< attach3 >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Date: Fri, 02 Mar 2001 10:20:36 -0500
From: Raghuram Rajah <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-trade-voucher-lang-00.txt
To: [email-masked]

Hi,

A few thoughts about the Voucher definition.

4. Component Structure - Defining the components associated with the voucher 
itself (like ValidPeriod), seem to constraint the potential of the voucher. 
Wouldn't it be better to define a overall framework that can support an 
ability to define meta-data and behaviour. We can standardize some meta-data 
like ValidPeriod, but the issuer should be able to define more.

Also, in one of Ko's earlier presentation (when discussing requirements), I 
saw a division of the voucher into two parts - Definition and the actual 
voucher. I felt the approach was admirable, for it provided a mechanism to 
define the shape of the voucher and the data as two seperate entities.Making 
a distinction between the core voucher and the meta-description information, 
helps a lot when the voucher has to be stored on a limited device like the 
smart card.

We had built a "voucher" (we called it coupon) system for the smart card. 
Let me go over that design philosophy, which are in line with one of Ko's 
earlier presentation. Thus, I would think the voucher is defined by two 
entities,

- Voucher Definition. Defines the shape and behaviour of the voucher.
- Voucher Instance. The core data of the voucher based on the defintion.

The Voucher Definition defines the genre of coupon,

eg. x% off any purchase greater than $y between m1/d1/y1 and m2/d2/y2 - Defn 
A
    $x off purchase at YYY Store - Defn B

The Voucher Instance on the other hand is the actual coupon that specifies 
the values of variables,

eg. Coupon Defn A; x=5; y=25; m1/d1/y1 = 11/2/2000; m2/d2/y2 = 12/25/2000
    Coupon Defn B; x=25; YYY = Sears

One of our initial XML DTDs looked like this,

CouponInstance DTD
~~~~~~~~~~~~~~~~~~

<!DOCTYPE BlueCoupon [

  <!ELEMENT BlueCoupon (CouponDefinition, Value, Constraint*,
			Signature?, CouponData?,
			Keyword?)>
  <!ATTLIST BlueCoupon ID #REQUIRED>    <!-- Numeric, upto 13 digits -->

  <!ELEMENT CouponDefinition (CouponProviderID, CouponDefinitionID)>
  <!ELEMENT CouponProviderID (#PCDATA)>  <!-- Numeric, upto 5 digits -->
  <!ELEMENT CouponDefinitionID (#PCDATA) <!-- Numeric, upto 8 digits -->

  <!ELEMENT Value (#PCDATA)             <!-- Numeric, 32-bit unsigned -->

  <!ELEMENT Constraint (#PCDATA)>       <!-- data type specified in the 
Definition -->
  <!ATTLIST Constraint ID #REQUIRED>    <!-- Numeric 16-bit, Unique, should 
be present in Defn-->

  <!ELEMENT Signature (#PCDATA)         <!-- doesn't include keywords -->
  <!ELEMENT CouponData (#PCDATA)	<!-- user data, optional -->

  <!ELEMENT Keyword ANY>                <!-- defined by the Provider -->

]>

CouponDefinition DTD
~~~~~~~~~~~~~~~~~~~~

<!DOCTYPE BlueCouponDefinition [

  <!ELEMENT BlueCouponDefinition (CouponType, ConstraintDefn*,
                                  Resource?, SignatureProperties)>
  <!ATTLIST BlueCouponDefinition ID #REQUIRED>      <!-- Numeric, upto 8 
digits -->

  <!ELEMENT CouponType (Stateful?, ValueType)>
  <!ELEMENT Stateful EMPTY>
  <!ELEMENT ValueType (#PCDATA)> <!-- Type to be understood by the using 
system -->

  <!ELEMENT ConstraintDefn (Name?, Description?, Type, Behaviour)>
  <!ATTLIST ID #REQUIRED>        <!-- This is used to specify values in the 
instance,
                                      and should be sequential for 
bluecoupon -->
  <!ELEMENT Name (#PCDATA)>
  <!ELEMENT Description (#PCDATA)>
  <!ELEMENT Type (Scalar | Currency | Floating | Date | String | Int32 | 
Int16)>
  <!ELEMENT Behaviour (Equal | NotEqual | Greater | GreaterEqual | Lesser | 
LesserEqual)

  <!ELEMENT Resource (Promise?, Icon?)>
  <!ELEMENT Promise (#PCDATA)>   <!-- url for the textual description of the 
promise -->
  <!ELEMENT Icon (#PCDATA)>      <!-- url for the icon associated with the 
promise -->

  <!ELEMENT SignatureProperties (SignatureMethod)> <!-- we might have to 
include the
                                                       encryption key too 
here, lets see -->
  <!ELEMENT SignatureMethod (#PCDATA)> <!-- method understood by using 
system
                                            like SHA-1 or MD5 -->

]>

EXAMPLE
~~~~~~~

<BlueCouponDefinition ID=78698563>
<CouponType>
  <ValueType>Percent</ValueType>
</CouponType>

<ConstraintDefn ID=1>
  <Name> MinPurchaseInCurrency </Name>
  <Type> Currency </Type>
</ConstraintDefn>

<ConstraintDefn ID=2>
  <Name> ValidityEndDate </Name>
  <Type> Date </Type>
</ConstraintDefn>

<ConstraintDefn ID=3>
  <Name> Vendor </Name>
  <Type> Numeric-5 </Type>
</ConstraintDefn>

<SignatureProperties>
  <SignatureMethod>SHA-1</SignatureMethod>
</SignatureProperties>
</BlueCouponDefinition>

<BlueCoupon ID=36948935845189>
<CouponDefinition>
  <CouponProviderID>12345</CouponProviderID>
  <CouponDefinitionID>78698563</CouponDefinitionID>
</CouponDefinition>

<Value>20</Value>

<Constraint ID=1>50</Constraint>
<Constraint ID=2>12/20/2000</Constraint>
<Constraint ID=3>45282</Constraint>

<Signature>94675745756756772</Signature>

<Keyword>
  <Category>General Merchandise
</Keyword>
</BlueCoupon>

Common Keywords/Constraints
~~~~~~~~~~~

Keywords
  - Category
  - Zipcode
  - City

Constraints
  - Product
  - Vendor
  - ValidityStartDate
  - ValidityEndDate
  - MaxUsageCount
  - Circulation
  - MinPurchaseCurrency
  - MaxPurchaseCurrency
  - MinPurchaseQty
  - MaxPurchaseQty
  - MaxCouponValue

>From: [email-masked]
>Reply-To: [email-masked]
>To: IETF-Announce: ;
>CC: [email-masked]
>Subject: I-D ACTION:draft-ietf-trade-voucher-lang-00.txt
>Date: Thu, 22 Feb 2001 07:04:37 -0500
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Internet Open Trading Protocol Working 
>Group of the IETF.
>
>	Title		: XML Voucher: Generic Voucher Language
>	Author(s)	: K. Fujimura
>	Filename	: draft-ietf-trade-voucher-lang-00.txt
>	Pages		: 8
>	Date		: 21-Feb-01
>
>This document specifies rules for defining voucher properties in
>XML syntax. A voucher is a logical entity that represents a right
>to claim goods or services. A voucher can be used to transfer a
>wide-range of electronic-values, including coupons, tickets,
>loyalty points, and gift certificates, which are often necessary to
>process in the course of payment and/or delivery transactions.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-lang-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-trade-voucher-lang-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-trade-voucher-lang-00.txt".
>
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
><< attach3 >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Date: Fri, 02 Mar 2001 14:37:01 +0000
From: Rachel Willmer <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: Ko Fujimura <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

Rachel Willmer wrote on the IETF IOTP mailing list:

>> Have there been any implementations of this Internet Draft on "XML
>> Voucher: Generic Voucher Language" ?

On 01 March 2001 14:29 +0900 Ko Fujimura <[email-masked]> replied

> Not yet. This document is newly designed and not completed as you see
> t.b.s.  sections. If major design issues are acceptable for the WG
> members, we would  like to go into detail.
>
> But I think it is easy to implement on top of existing value transfer
> protocols since we designed it based on our implementation experiences of
> several types  of value transfer protocols and languages. I hope some
> volunteers could also  help to check feasibility and give feedback about
> the specification.

Ko

Are you familiar with Systemics Ricardo system, which uses Ricardian 
contracts to implement the concept that you call "vouchers"?

	<http://www.systemics.com>

This system has been around for about 5 years and has been used in the 
fields of currency, stocks and bonds. The use of "Ricardian contracts" or 
"vouchers" is a critical part of the architecture.

I've copied this mail to Ian Grigg from Systemics <[email-masked]>, 
because I think it may be worth you both engaging in some dialogue.

We're in the process of integrating their Ricardo system into our 
CashBox(tm) system, and I'm interested in knowing about any other companies 
who may be implementing other payment systems based on these concepts, so 
please do let me know when others do implement.

Regards
Rachel

Date: Thu, 01 Mar 2001 14:29:20 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: implementations of "XML Voucher: Generic Voucher Language" ?
To: Rachel Willmer <[email-masked]>
Cc: [email-masked]

Rachel Willmer wrote:
> 
> Have there been any implementations of this Internet Draft on "XML Voucher:
> Generic Voucher Language" ?
> 
> Thanks
> Rachel

Not yet. This document is newly designed and not completed as you see t.b.s. 
sections. If major design issues are acceptable for the WG members, we would 
like to go into detail.

But I think it is easy to implement on top of existing value transfer protocols
since we designed it based on our implementation experiences of several types 
of value transfer protocols and languages. I hope some volunteers could also 
help to check feasibility and give feedback about the specification.

Thanks,

Ko