Re: implementations of "XML Voucher: Generic Voucher Language" ?

[lynn.wheeler@firstdata.com]

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 <fujimura@isl.ntt.co.jp> on 03/09/2001 05:17:48 AM

To:   iang@systemics.com
cc:   Lynn Wheeler/CA/FDMS/FDC@FDC, Rachel Willmer <rachel@intertrader.com>,
      dbs@philodox.com, ietf-trade@lists.elistx.com
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