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

From: Raghuram Rajah <[email-masked]>
Date: Fri, 02 Mar 2001 10:20:36 -0500

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

---

From: Ko Fujimura <[email-masked]>
Date: Mon, 05 Mar 2001 15:27:24 +0900

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

>     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