Subject: I-D ACTION:draft-ietf-trade-voucher-lang-03.txt

From: [email-masked]
Date: Tue, 18 Jun 2002 07:26:48 -0400

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, M. Terada
	Filename	: draft-ietf-trade-voucher-lang-03.txt
	Pages		: 19
	Date		: 17-Jun-02
	
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-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-03.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-03.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.

---

From: Ko Fujimura <[email-masked]>
Date: Tue, 18 Jun 2002 21:47:45 +0900

Hello,

We updated the draft as you noticed. The changes we made from the previous 
version are only a few points:

(1) Based on the recent draft [XML-Registry], targetNamespace of XML Voucher 
    was changed from:
         "http://www.ietf.org/rfc/rfcXXXX"
    to:
         "urn:ietf:params:xml:schema:vts-lang"
    Added IANA Consideration section 7 for call IANA to register this 
    schema. 

    [XML-Registry] M. Mealing, "The IETF XML Registry",
    draft-mealling-iana-xmlns-registry-03, November 2001.

(2) Deleted below sentences in 6.8 <Value> because they are too specific:

    Discount: ... "Only one sheet of voucher can be used for a single 
      purchase of the item. The discount values for a single purchase of 
      the item must not exceed the retail price."
    Monetary: ... "Multiple vouchers can be redeemed for purchasing a 
      single item. If the total value of the vouchers exceeds the retail 
      price, changes will be given."

(3) Deleted below sentence in 6.5 <Issuer>, last sentence of the paragraph
    starting from "If the <Issuer> element is omitted ..."

      "The issuer role (responsibility for the contents of the voucher) is 
       delegated to the VTS Provider"

    It was a mistake. The issuer is managed by the VTS and no need to 
    delegate its responsibility to the VTS Provider.

Any comments are welcome.

We are also going to update the VTS-API draft soon. But changes we 
intended for the next version are also minor.

Thanks,

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

---

From: Donald Eastlake 3rd <[email-masked]>
Date: Tue, 18 Jun 2002 08:58:56 -0400 (EDT)

Hi,

I suggest that in the next version of this an ID attribute should be
added to voucher. To assure uniqueness, we might also recommend that the
ID value be the based64 of a hash of the Exclusive Canonicalization
<http://www.w3.org/TR/xml-exc-c14n> of the voucher element with the ID
attribute dropped out. That is, something like

Base64 ( SHA1 ( ExclusiveCanonicalization (
           XPath ( voucher,
	           ( //. |
                     //namespace::* |
                     /@[ localname() != Id ] |
                     /descendant::node()/@
                   ) )
)))

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

On Tue, 18 Jun 2002 [email-masked] wrote:

> Date: Tue, 18 Jun 2002 07:26:48 -0400
> From: [email-masked]
> To: IETF-Announce:  ;
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-trade-voucher-lang-03.txt
>

---

From: Ko Fujimura <[email-masked]>
Date: Wed, 19 Jun 2002 13:45:36 +0900

Hello Donald and all,

>                      /@[ localname() != Id ] |

Thank you for inputting a good idea. Actually, I received a comment 
below about 3 month ago regarding this issue:

> > > We are currently working on a project where tickets are
> > > stored in a central system and
> > > can be sold by retailers using a POS terminal in a shop. The
> > > terminal communicates
> > > via GSM (SMS/internet/direct) to the central system.
... (snip)
> > > So here they are:
> > >
> > > 1. We need some unique number for every type of ticket to
> > >    identify the ticket.
> > >    If the terminal ask for a certain type of ticket we want
> > >    to search for this ticket-type in the central database.
> > >    I was looking for adding this number in the 'issuer'
> > >    part, but I think there needs
> > >    to be some global authorization organization for ticket
> > >    identifiers. What are you're thoughts about this?

I have been reluctant to add ID attribute to <Voucher> because
I think an implementation may use the hash value of the whole
Voucher Component as the unique identifier of the <Voucher>.
In this case, I thought it impossible to define the hash value 
as the value of ID attribute within the <Voucher>, which is the 
subject to calculate the hash value. But, Donald's idea enables 
us not to include the hash in itself. So, I agree to add ID
attribute to the <Voucher>. Any opinions?

Best regards,

Ko

---

From: Ian Grigg <[email-masked]>
Date: Wed, 19 Jun 2002 10:24:00 -0400

Hi all,

(I think I've been blind CC'd by Mr Fujimura, apologies
for leaping in here.)

> >                      /@[ localname() != Id ] |

I would fully approve of using the SHA1 of the "voucher"
as the unique identifier.  We've been using this with
Ricardian Contracts since 1995, and it has worked well.

In fact, it is a critical piece of the architecture,
allowing for a reduction of administration over all
other payment schemes that exist.  It literally
eliminates the need to control the issuance of new
contracts ("vouchers" in your system), which massively
expands the applicability.  It also enforces agreement
on the text of the contract with very little adminstration.

(It is critical to get the canonicalisation correct, of
course.  But you seem to already have that under control.)

> attribute to the <Voucher>. Any opinions?

I wonder why you would want to do that?  Thinking in
normalisation terms (c.f. Codd) this is a duplication
of information.  Thus, you would have to think of the
case for the wrong identifier being in place.  This
would be a bug, and would introduce complications into
the architecture.

I thought this morning about how I would add the digest
to the Ricardian Contract and realised that it would
break the notion of the contract.  Part of the security
of the system resides on the ability for all parties to
agree on the text, via the compression into the digest.
By offering a short cut, this would introduce a security
flaw into the Ricardo architecture which would impact on
a lot of the governance.

Now, maybe your vouchers are not necessarily considered
to be contractually strong, in the Ricardian sense, so
maybe you don't face the same security concerns.  And,
maybe there is a reason for caching the number.  But I
don't see it.

In practice, digest cycles are cheap.  I would suggest
that you want to look carefully at calculating the digest
on the fly rather than storing it in the voucher.  And,
if it were cached, consider very carefully what that
means, and why!

-- 
iang