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

From: Raghuram Rajah <[email-masked]>
Date: Fri, 02 Mar 2001 10:20:47 -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