Trade Working Group                                      February                                           May 2001
INTERNET-DRAFT                                             Ko Fujimura
                                                       Masayuki Terada
Expires: August November 2001                                             NTT

                XML Voucher: Generic Voucher Language
                <draft-ietf-trade-voucher-lang-00.txt>
                <draft-ietf-trade-voucher-lang-01.txt>

Status of This Document

 This document is an Internet-Draft and is in full conformance with
 all provisions of Section 10 of RFC2026.

 Internet-Drafts are working documents of the Internet Engineering
 Task Force (IETF), its areas, and its working groups.  Note that
 other groups may also distribute working documents as Internet-
 Drafts.

 Internet-Drafts are draft documents valid for a maximum of six months
 and may be updated, replaced, or obsoleted by other documents at any
 time.  It is inappropriate to use Internet-Drafts as reference
 material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

 Distribution of this document is unlimited. Please send comments to
 the TRADE  working group at <ietf-trade@lists.elistx.com>, which may
 be joined by sending a message with subject "subscribe" to <ietf-
 trade-request@lists.elistx.com>.

 Discussions of the TRADE working group are archived at
 http://www.elistx.com/archives/ietf-trade.
 http://lists.elistx.com/archives/ietf-trade.

Abstract

   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.

Table of Contents

   Status of this Memo ..............................................1 ...............................................1
   Abstract .........................................................1 ..........................................................1
   1. Introduction ..................................................2 ...................................................2
   2. Processing Model ..............................................2 ...............................................3
   3. Trust Model ...................................................3 ....................................................4
   4. Component Structure ...........................................4 ............................................4
      4.1 Voucher Component .........................................4 ..........................................4
      4.2 Promise Component .........................................4 ..........................................5
   5. Syntax Overview and Examples ..................................6 ...................................7
   6. Syntax and Semantics .....................................................7 ...........................................8
      6.1 <Voucher> ..................................................8
      6.2 <Provider> .................................................8
      6.3 <Issuer> ...................................................9
      6.4 <Promise> ..................................................9
      6.4.1 <Title> .................................................10
      6.4.2 <Description> ...........................................10
      6.4.3 <Value> .................................................10
      6.4.3.1 <Ratio> ...............................................11
      6.4.3.2 <Fixed> ...............................................12
      6.4.4 <ValidPeriod> ...........................................12
      6.4.5 <Merchandise> ...........................................13
      6.4.6 <Conditions> ............................................13
      6.5 <Holder> ..................................................14
   7. DTD ...........................................................7 Schemas .......................................................14
   8. VTS Schema Example ............................................16
   9. Security Considerations .......................................7
   9. Acknowledgments ...............................................7 .......................................17
  10. References ....................................................7 Acknowledgments ...............................................17
  11. References ....................................................17
  12. Author's Address ..............................................8 ..............................................17

1. Introduction

   This document, XML Voucher, specifies rules for defining voucher
   properties in XML syntax. The motivation and background of the
   specification is are described in [GVT].

   A voucher is a logical entity that represents a certain right and
   is logically managed by the Voucher Trading System (VTS). A voucher
   is generated by the issuer, and traded among users, and finally is
   collected by the collector using VTS.

   This document defines the syntax and semantics of the Voucher Component
   that is used to define
   Component, which defines voucher meaning and processing rules in
   XML syntax [XML]. In a A Voucher Component, Component defines the properties needed that
   must be satisfied to allow the voucher to be processed by VTS or
   other trading systems, e.g., wallet or merchant system, are described. system. VTS
   definitions and models are also defined in [GVT].

   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.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC 2119]

2. Processing Model

   There are several ways of implementing VTS and technologies are
   continuously
   continually changing. For discount coupons or event tickets, for
   example, the smart-card-based offline VTS is often preferred,
   whereas for bonds or securities, the centralized online VTS is
   preferred. It is impractical to define standard protocols for
   issuing, transferring, or redeeming vouchers at this moment.

   To provide implementation flexibility, this document assumes a
   modular wallet architecture that allows multiple VTS to be added as
   plug-ins. In the this architecture, instead of specifying a standard
   voucher transfer protocol, two specifications, i.e., Voucher
   Component and VTS API specifications, are standardized (Figure 1).

   Sender wallet/Issuing system      Receiver wallet/Collecting system
   +---------------------------+       +---------------------------+
   |                           |       |                           |
   |  |                    Voucher Component                    |  |
   |  |  (Specifies Issuer, Promise, Holder, and VTS Provider)  |  |
   |  |-------------------------------------------------------->|  |
   |  |                        |       |                        |  |
   |  |         Intention to receive and payment (option)       |  |
   |  |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - |  |
   |  |                        |       |                        |  |
   |  |                        |       |                        |  |
   |  | Issue/transfer/  VTS   |       |   VTS      Register    |  |
   |  | redeem request   plug-in       |   plug-in    request   |  Listener(*1)|  |
   |  |------------------>|    |       |    |<------------------|  |
   |  | (VTS API)         |<- - - - - - - ->|         (VTS API) |  |
   |  |                   | VTS-specific    |                   |  |
   |  |                   | protocol if VTS |                   |  |
   |  |                   | is distributed  |                   |  |
   |  |   Event  Result           |<- - - - - - - ->|           Event       Notify(*2)  |  |
   |  |<------------------|    |       |    |------------------>|  |
   +---------------------------+       +---------------------------+
   (*1) Registration is optional. Note also that the VTS plug-ins are
        usually pre-registered when the wallet or collecting system
        is started.
   (*2) If a listener is registered.

           Figure 1. Wallet architecture with VTS plug-ins
   After sender and receiver agree on what vouchers are to be traded
   and which VTS is to be used, the issuing system or wallet system
   requests the corresponding VTS plug-in to permit the issue,
   transfer, or redeem transactions to be performed via the VTS
   API. The VTS then rewrites the ownership of the vouchers using a the
   VTS-specific protocol. Finally, a completion event is sent to the
   wallet systems or issuing/collecting systems.

   This document describes the Voucher Component specification. The
   VTS API specification will be published as a separate document.

3. Trust Model

   A voucher is trusted if the issuer Issuer and VTS provider Provider are trusted,
   since the issuer Issuer is responsible for the contents of the voucher and
   the VTS provider Provider is responsible for preventing ownership from being
   assigned to multiple users. This model enables trading partners to
   verify the trust of the voucher regardless of the trust of the
   partners.

   The trust level required for issuer Issuer and VTS provider Provider depends on the
   type (or Promise) of the voucher. To provide the information needed
   for the verification, the conditions of issuer Issuer and VTS provider Provider are
   specified in the Voucher Component, and given as input to the
   verifier, e.g., wallet system or other software. The trust of a
   voucher is thus verified through the Voucher Component.

   In this case, however, if This model
   enables trading partners to verify their trust in the voucher
   regardless of their trust in the partners.

   This document assumes that the Voucher Component is the root of
   trust. If a malicious user could alter the Voucher Component, a
   forged voucher, would voucher could be verified as valid. This
   document, therefore, assumes that such alteration is impossible
   during delivery of the

   The Voucher Component; this Component is possible with
   existing technologies, usually delivered from the trusted VTS
   Provider, Issuer or trusted third party using a secure
   communication channel, such as [XMLDSIG] [XMLDSIG], [TLS], or [TLS].
   [IPSEC]. Delivery of the Voucher Component is beyond the scope of
   this document.

   Note: The Voucher Component does not have to be sent from the
   sender of the voucher. It can be directly delivered from the
   trusted issuer or trusted third party using TLS or other secure
   communication channel. Note also that a set of trusted Voucher
   Components can be pre-downloaded downloaded before conducting a transaction.

4. Component Structure
4.1 Voucher Component

   A Voucher Component provides VTS branding Provider information, and basic
   properties for representing a voucher, i.e., issuer, promise, Issuer, Promise, and
   holder.
   Holder. Implementation-specific properties are often required for
   authenticating issuer VTS Provider, Issuer and holder. Holder. These
   implementation-specific properties of the VTS can be attached as
   child elements using [XML-ns].

   The Voucher Component contains Provider Component, Issuer
   Component, Promise Component, and Holder Component as follows:

   Provider Component

     Provides properties to that specify which VTS Provider (or VTS
     plug-in) can be used for trading the voucher.

   Issuer Component

     Provides properties specifying the issuer Issuer of the vouchers.  This
     is optional and can be omitted if the issuer Issuer role is delegated to
     the VTS Provider.

   Promise Component

     Provides properties used by the application system of VTS, e.g.,
     wallet system, merchant system. The Promise Component is
     transparent to the VTS and is described in Section 4.2.

   Holder Component

     Provides properties to that specify the holder Holder of the vouchers. This
     is optional and can be omitted if the vouchers are transferable. (Note: Even for transferable vouchers, this
     component may be used by the VTS depending on the
     implementation.)

4.2 Promise Component

   The Promise Component provides the information needed to identify
   the monetary value or merchandize rendered when the voucher is
   redeemed.  It includes:

   o How much value/items can be claimed in exchange for the voucher

   o Restrictions applied to the voucher
     - Objects (merchandise) to be claimed
     - Time when valid (validity period)
     - Others

   The Promise Component also provides common properties useful for
   displaying and manipulating the contents of wallet systems. It
   includes monetary
   property (value) of the title and description of each voucher. These monetary properties are
   needed to calculate the amount paid when the vouchers are redeemed
   at Merchant site, etc.

   The Promise Component contains the Title Component, Description
   Component, ValidPeriod Value Component, Redemption ValidPeriod Component, Merchandise
   Component, and Value Condition Component as follows:

   Title Component

     Provides the title of the voucher. This is mainly for displaying listing
     the list of entities stored in a wallet system.

   Description Component

     Provides a short description of the voucher. This is mainly for
     displaying
     listing the entities stored in a wallet system.

   ValidPeriod

   Value Component

     Indicates voucher's validity period, start date

     Provides the value of each voucher. There are two types of
     values, i.e., fixed and end date.

   Redemption ratio values. For a fixed value, the
     currency and the figure is specified. For a ratio value, the
     discount ratio of the corresponding merchandize is specified.

     The Value Component

     Provides also indicates the number of vouchers to be
     redeemed for claiming the merchandise or financial monetary value specified
     in Merchandise Component or Value Component. If "n" (>0) "n"(>0) is
     specified, the merchandize or monetary value can be claimed in
     exchange with for "n sheets of" vouchers. (Note:
     Multiple vouchers for the same Voucher Component must exist in
     this case.)  If "0" is specified, the vouchers do not need to be
     consumed. It it
     can be used repeatedly regardless of repeatedly.

   ValidPeriod Component

     Provides restrictions on the number validity period of
     times redeemed. the voucher,
     i.e., start date and end date.

   Merchandise Component

     Provides domain-specific restrictions on the object to be claimed.
     Domain-specific meaning of the voucher, e.g., reference number of
     the merchandize or seat number for an event ticket,
     which is needed specified
     to identify the merchandize rendered when the voucher is
     redeemed. The properties of this component are left

   Condition Component

     Provides any other applicable restrictions. This is intended to
     cover contracts between the other domain-specific specifications issuer and out holder of scope the
     voucher in natural language form.

   Using the above Components, semantics for diverse types of this
     document. Domain-specific properties vouchers
   can be attached defined as child
     elements using [XML-ns]. shown in Table 1.

   +----------------+--------------------------------+---------------+
   |                |             Value Component

     Provides the value of the vouchers. There are two types of
     values, i.e., fixed and ratio values. For a fixed value, the
     currency and amount of the value is specified. For a ratio value,
     the discount ratio of the price of the corresponding merchandize
     is specified.

   Using the above Components, monetary meaning for diverse types of
   vouchers can be defined as shown in Table 1.

   +---------------+----------+---------------+---------------------+
   |               |Number              |  Restrictions |        Value
   |                +-----+---------------+----------+---------------+
   |   Examples    |needed for|  Merchandise  +-----+---------------+
   |               |redemption|     |Ratio|    Fixed      |Number    |  Merchandise  |
   |                |     +------+--------+Needed for|               |
   |                |     |Amount Currency|
   +---------------+----------+---------------+-----+------+--------+     |Amount|Currency|redemption|               |
   +----------------+-----+------+--------+----------+---------------+
   |Gift certifiate|        1 |(Not specified)| certificate|     |   25 |  USD   |        1 |(Not specified)|
   |Loyalty point   |       20 |(Not specified)|     |  200 |  AUD   |       20 |(Not specified)|
   |Member card     |  20%|      |        |        0 |(Not specified)|  0.2|
   |Coupon          |  30%|      |
   |Coupon        |        1 |Beef 500g      |  0.3|      |        |
   |Event ticket    | 100%|      |        |        1 |Hall A, S ,K23 |  1.0|
   |Exchange ticket | 100%|      |        |
   |Exchange ticket|        1 |ISBN:0071355014|  1.0|      |        |
   +---------------+----------+---------------+-----+------+--------+
   +----------------+-----+------+--------+----------+---------------+
          Table 1. Examples of vouchers and their properties

5. Syntax Overview and Examples

   This section provides an overview and examples of Voucher
   Component.  The formal syntax and semantics are found in Sections 6
   and 7.

   Voucher Components are represented by the <Voucher> element which
   has the following structure (where "?" denotes zero or one
   occurrence; "+" denotes one or more occurrences; and "*" denotes
   zero or more occurrences):
   occurrence):

   <Voucher>
     (Provider)
     (Issuer)?
     <Promise>
       (Title)?
       (Description)?
       (Value)
       (ValidPeriod)?
       (Redemption)?
       (Value)?
       (Merchandise)+
       (Merchandise)?
       (Conditions)?
     </Promise>
     (Holder)?
   </Voucher>

   An example of a Voucher Component is described below. This is an
   example of a five dollar discount coupon for specific merchandize,
   a book with ISBN number 0071355014. The coupon is valid from April
   1st in 2001 to March 31st in 2002. To claim this offer, one voucher
   must be spent.

   <?xml version="1.0"?>
   <Voucher xmlns="http://www.ietf.org/rfc/rfcXXXX.txt"
            xmlns:vts="http://www.example.com/vts.txt"> xmlns="http://www.ietf.org/rfc/rfcXXXX"
            xmlns:vts="http://www.example.com/vts">
     <Provider Name="Voucher name="Voucher Wallet 2001">
       <vts:KeyInfo>...</vts:KeyInfo>
       <vts:Version>2.31</vts:Version>
     </Provider>
     <Issuer Name="Alice name="Alice Book Center, Ltd.">
       <vts:KeyInfo>...</vts:KeyInfo>
       <vts:KeyInfo>1DA8DFCF95521014BBB7171B95545E8D61AE803F
       </vts:KeyInfo>
     </Issuer>
     <Promise>
       <Title>IOTP Book Coupon</Title>
       <Description>$5 off IOTP Book</Description>
       <Value type="discount" spend="1">
        <Fixed amount="5" currency="USD"/>
       </Value>
       <ValidPeriod start="2001-04-01" end="2002-03-31"/>
       <Redemption spend="1"/>
       <Value currency="USD" amount="5"/>
       <Merchandise xmlns="http://www.example.com/book.txt">
         <BookID ISBN="0071355014"/>
       <Merchandise>
         <bk:BookID xmlns:bk="http://www.example.com/book"
                    bk:ISDN="0071355014"/>
       </Merchandise>
       <Conditions>It can be claimed only at Alice Book Center.

       </Conditions>
     </Promise>
   </Voucher>

6. Syntax and Semantics
   (tbs)

7. DTD
   (tbs)

8. Security Considerations

   Security issues for delivering

   The general structure of an XML voucher is described in Component
   Structure (section 4).  This section details the Voucher Components are discussed Component
   features.  Features described in
   Section 3. Security this section MUST be implemented
   unless otherwise indicated.  The syntax is a major issue in implementing VTS. defined via
   [XML-Schema-1] [XML-Schema-2]. For XML
   Voucher, however, the only requirements for achieving security clarity, unqualified elements in
   schema definitions are
   to provide in the parameters needed for establishing security.

9. Acknowledgement
   (tbs)

10. XML schema namespace:

       xmlns="http://www.w3.org/2001/XMLSchema"

   References

   [ECML] ECML Version 2, to appear.

   [GVT] K. Fujimura, "Requirements for Generic the XML Voucher Trading",
   draft-ietf-trade-drt-requirements-02.txt, February 2001.

   [IOTP] D. Burdett, "The Internet Open Trading Protocol", RFC2801,
   April 2000.

   [RFC2119] S. Bradner, "Key words for schema defined herein use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246,
   January 1999.

   [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A
   W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000.

   [XMLDSIG] "XML-Signature Syntax the prefix
   "gvl" and Processing",
   draft-ietf-xmldsig- core-11.txt, are in RFC Editor queue the namespace:

       xmlns:gvl="http://www.ietf.org/rfc/rfcXXXX.txt"

   This namespace is also used for
   publication as Proposed Standard.

   [XML-ns] "Namespaces unqualified elements in XML", A W3C Recommendation,
   <http://www.w3.org/TR/REC-xml-names>, January 1999.

11. Authors voucher
   examples.

6.1 <Voucher>

   The <Voucher> element contains <Provider> and <Promise> elements
   and optionally contains <Issuer> and <Holder> elements. These
   sub-elements are defined in the following sections.

   The <Voucher> element is defined by the following schema:

    <element name="Voucher" type="gvl:VoucherType"/>
    <complexType name="VoucherType">
     <sequence>
      <element ref="gvl:Provider"/>
      <element ref="gvl:Issuer" minOccurs="0"/>
      <element ref="gvl:Promise"/>
      <element ref="gvl:Holder" minOccurs="0"/>
     </sequence>
    </complexType>

6.2 <Provider>

   The <Provider> element may contain any elements that are used to
   specify or restrict the VTS Provider of the voucher.  The
   sub-elements contained in this element depend on the implementation
   of the VTS.

   An implementation of a wallet system may use this information to
   identify and/or authenticate the VTS Provider when the VTS plug-in
   is registered. These implementation-specific elements of the VTS
   can be extended using [XML-ns]. An example of such schema
   definition is described in Section 8.

   The <Provider> element has a string-type "name" attribute that is
   used to specify the name of the VTS Provider.

   The <Provider> element is defined by the following schema:

    <element name="Provider" type="gvl:RoleType"/>
    <complexType name="RoleType">
     <sequence>
      <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
     <attribute name="name" type="string" use="required"/>
    </complexType>

6.3 <Issuer>

   The <Issuer> element may contain any element that is used to
   specify or restrict the Issuer of the voucher.  The sub-elements
   contained in this element depend on the implementation of the
   VTS. An implementation of a VTS often requires it to describe the
   authentication data of the Issuer. These implementation-specific
   elements of the VTS can be extended using [XML-ns].

   The <Issuer> element has a string-type "name" attribute that is
   used to specify the name of the Issuer.

   The <Issuer> element is defined by the following schema:

   <element name="Issuer" type="gvl:RoleType"/>
   The <RoleType> element type is defined in Section 6.2.

   If the <Issuer> element is omitted, it MUST be interpreted that the
   issuer role is delegated to the VTS Provider.

6.4 <Promise>

   The <Promise> element contains a <Value> element and optionally
   <Title>, <Description>, <ValuePeriod>, and <Condition>
   elements. These sub-elements are defined in the following sections.

   The <Promise> element is defined by the following schema:

    <element name="Promise" type="gvl:PromiseType"/>
    <complexType name="PromiseType">
     <sequence>
      <element ref="gvl:Title"       minOccurs="0"/>
      <element ref="gvl:Description" minOccurs="0"/>
      <element ref="gvl:Value"/>
      <element ref="gvl:ValidPeriod" minOccurs="0"/>
      <element ref="gvl:Merchandise" minOccurs="0"/>
      <element ref="gvl:Conditions"  minOccurs="0"/>
     </sequence>
    </complexType>

6.4.1 <Title>

   The <Title> element contains a simple text title of the voucher.
   This is mainly for listing the entities stored in a wallet system.

   The <Title> element has no attribute.

   The <Title> element is defined by the following schema:

    <element name="Title" type="string"/>

6.4.2 <Description>

   The <Description> element contains a simple text description of the
   voucher.  This is mainly for listing the entities stored in a
   wallet system.

   The <Description> element has no attribute.

   The <Description> element is defined by the following schema:

    <element name="Description" type="string"/>

6.4.3 <Value>

   The <Value> element optionally contains a <Fixed> or a <Ratio>
   element but not both. These sub-elements are defined in the
   following sections.

   The <Value> element has a "type" attribute that is used to specify
   the value process type. This attribute is provided to calculate the
   amount paid when the vouchers are redeemed at Merchant site, etc.

   The following identifiers are defined for the "type" attribute.

   Exchange: Items specified in the <Merchandise> element can be
     claimed in exchange for the voucher. If this type is selected,
     neither <Ratio> nor <Fixed> element MUST be specified. Note that
     this value process type has the same meaning as:
     <Value type="discount"><Ratio percentage="100"/></Value>

   Discount: Items specified in the <Merchandise> element can be
     purchased at the discount price calculated by the <Ratio> or
     <Fixed> element. 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: Items specified in the <Merchandise> element can be
     purchased using the value of the voucher. (Note: if the
     <Merchandise> element is not specified, the voucher can be used
     for any purchase.) If this type is selected, the <Fixed> element
     MUST be specified. 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.

   The <Value> element also has a "spend" attribute that is used to
   specify the number of vouchers to be redeemed for claiming the
   goods, services, or monetary value specified. For example, if "n"
   (>0) is specified, goods etc. can be claimed in exchange for "n
   sheets of" vouchers. (Note: Multiple vouchers for the same Voucher
   Component must exist in this case.)  If "0" is specified, it can be
   used repeatedly.

   If the "spend" attribute is omitted or the whole element is omitted,
   it MUST be interpreted that "0" is specified for the "spend"
   attribute.

   The <Value> element is defined by the following schema:

    <element name="Value" type="gvl:ValueType"/>
    <complexType name="ValueType">
     <sequence minOccurs="0">
      <choice>
       <element name="Ratio" type="gvl:RatioValueType"/>
       <element name="Fixed" type="gvl:FixedValueType"/>
      </choice>
     </sequence>
     <attribute name="type" type="gvl:ValueProcessType"
                use="required"/>
     <attribute name="spend" type="nonNegativeInteger"
                default="1"/>
    </complexType>

   The <ValueProcessType> element type is defined by the following
   schema:

    <simpleType name="ValueProcessType">
     <restriction base="string">
      <enumeration value="exchange"/>
      <enumeration value="discount"/>
      <enumeration value="monetary"/>
     </restriction>
    </simpleType>

6.4.3.1 <Ratio>

   The <Ratio> element does not contain any contents.

   The <Ratio> element has a "percentage" attribute that is used to
   specify the discount ratio of the price of the corresponding
   merchandize in percentage.

   The <RatioValueType> element type is defined by the schema:

    <complexType name="RatioValueType">
     <attribute name="percentage" use="required">
      <simpleType>
       <restriction base="float">
        <maxInclusive value="100"/>
       </restriction>
      </simpleType>
     </attribute>
    </complexType>

6.4.3.2 <Fixed>

   The <Fixed> element does not contain any contents.

   The <Fixed> element has "currency" and "amount" attributes
   and optionally a "decimalPower" attribute as follows:

   Currency: Provides the unit of the monetary value in the three
     letter ISO currency code [ISO4217].  For example, for US dollars
     it is "USD".

   Amount: Provides the amount of the monetary value per voucher.

   DecimalPower: Provides the number of decimal digits from the
     decimal point applied to the base for the "amount" attribute
     above. If the "decimalPower" attribute is omitted, it MUST be
     interpreted that "0" is specified for the "decimalPower"
     attribute.

   For example, with a dollar currency denominated in cents, "1" is
   specifed for the "amount" attribute, and "-2" is specified for the
   "decimalPower" attribute. Alternately, "0.01" is specified for
   the "amount" attribute and the "decimalPower" attribute is omitted.

   The <FixedValueType> type is defined by the following definition:

    <complexType name="FixedValueType">
     <attribute name="currency" type="string" use="required"/>
     <attribute name="amount" type="float" use="required"/>
     <attribute name="decimalPower" type="Integer" default="0"/>
    </complexType>

6.4.4 <ValidPeriod>

   The <VaridPeriod> element does not contain any contents.

   The <ValidPeriod> element has dateTime-type "start" and "end"
   attributes that are used to place limits on the validity of the
   voucher.

   The <ValidPeriod> element is defined by the following schema:

    <element name="ValidPeriod" type="gvl:ValidPeriodType"/>
    <complexType name="ValidPeriodType">
      <attribute name="start" type="dateTime"/>
      <attribute name="end" type="dateTime"/>
    </complexType>

   If the "start" attribute is omitted, it MUST be interpreted that
   the voucher is valid on any date up to the date (inclusive)
   specified by the end attribute. If the "end" attribute is omitted,
   it MUST be interpreted that the voucher is valid from the start
   attribute with no expiry. If neither attribute is specified or the
   whole element is omitted, it MUST be interpreted that the voucher
   is valid at any time.

6.4.5 <Merchandise>

   The <Merchandise> element may contain any elements used to specify
   or restrict the goods or services rendered when the voucher is
   redeemed.  The sub-elements contained in this element depend on the
   application of the voucher and are left to the other
   domain-specific specifications. Domain-specific elements can be
   extended as sub-elements using [XML-ns].

   The <Merchandise> element does not have any attribute.

   The <Merchandise> element is defined by the following schema:

    <element name="Merchandise" type="gvl:MerchandiseType"/>
    <complexType name="MerchandiseType" mixed="true">
     <sequence>
      <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
    </complexType>

   If the <Merchandise> element is omitted, it will be generally
   interpreted that there is no restriction on the merchandise when
   using the voucher.

6.4.6 <Conditions>

   The <Conditions> element may contain any element used to specify
   any other restrictions or conditions applied that limit the use of
   the voucher. The sub-elements contained in this element
   depend on the application of the voucher and are left to the
   other domain-specific specifications. Domain-specific elements can
   be extended as sub-elements using [XML-ns].

   The <Conditions> element does not have any attribute.

   The <Conditions> element is defined by the following schema:

    <element name="Conditions" type="gvl:ConditionsType"/>
    <complexType name="ConditionsType" mixed="true">
     <sequence>
      <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
    </complexType>

   If the <Conditions> element is omitted, it will be generally
   interpreted that there are no other restrictions or conditions on
   using the voucher.

6.5 <Holder>

   The <Holder> element may contain any element used to specify or
   restrict the Holder of the voucher.  The sub-elements contained in
   this element depend on the implementation of the VTS. An
   implementation of a VTS often requires this element to describe the
   authentication data of the Holder. These implementation-specific
   elements of the VTS can be extended using [XML-ns].

   The <Holder> element has a string-type "name" attribute that is
   used to specify the name of the Holder.  Note: Null string ("") MAY
   be specified for the name of the Holder if the name of the Holder
   is not given.

   The <Holder> element is defined by the following schema:

   <element name="Holder" type="gvl:RoleType"/>
   The <RoleType> element type is defined in Section 6.2.

   If the <Holder> element is omitted, it MUST be interpreted that the
   voucher is transferable. (Note: Even for transferable vouchers,
   this element may be used by the VTS depending on implementation
   needs.)

7. Schemas

   The collected XML schema specification is:

   <?xml version="1.0"?>

   <schema
    targetNamespace="http://www.ietf.org/rfc/rfcXXXX"
    xmlns:gvl="http://www.ietf.org/rfc/rfcXXXX"
    xmlns="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified">

    <element name="Voucher" type="gvl:VoucherType"/>
    <complexType name="VoucherType">
     <sequence>
      <element ref="gvl:Provider"/>
      <element ref="gvl:Issuer" minOccurs="0"/>
      <element ref="gvl:Promise"/>
      <element ref="gvl:Holder" minOccurs="0"/>
     </sequence>
    </complexType>
    <element name="Provider" type="gvl:RoleType"/>
    <element name="Issuer"   type="gvl:RoleType"/>
    <element name="Holder"   type="gvl:RoleType"/>
    <complexType name="RoleType">
     <sequence>
      <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
     <attribute name="name" type="string" use="required"/>
    </complexType>

    <element name="Promise" type="gvl:PromiseType"/>
    <complexType name="PromiseType">
     <sequence>
      <element ref="gvl:Title"       minOccurs="0"/>
      <element ref="gvl:Description" minOccurs="0"/>
      <element ref="gvl:Value"/>
      <element ref="gvl:ValidPeriod" minOccurs="0"/>
      <element ref="gvl:Merchandise" minOccurs="0"/>
      <element ref="gvl:Conditions"  minOccurs="0"/>
     </sequence>
    </complexType>

    <element name="Title" type="string"/>

    <element name="Description" type="string"/>

    <element name="Value" type="gvl:ValueType"/>
    <complexType name="ValueType">
     <sequence minOccurs="0">
      <choice>
       <element name="Ratio" type="gvl:RatioValueType"/>
       <element name="Fixed" type="gvl:FixedValueType"/>
      </choice>
     </sequence>
     <attribute name="type" type="gvl:ValueProcessType"
                use="required"/>
     <attribute name="spend" type="nonNegativeInteger"
                default="1"/>
    </complexType>

    <simpleType name="ValueProcessType">
     <restriction base="string">
      <enumeration value="exchange"/>
      <enumeration value="discount"/>
      <enumeration value="monetary"/>
     </restriction>
    </simpleType>

    <complexType name="RatioValueType">
     <attribute name="percentage" use="required">
      <simpleType>
       <restriction base="float">
        <maxInclusive value="100"/>
       </restriction>
      </simpleType>
     </attribute>
    </complexType>

    <complexType name="FixedValueType">
     <attribute name="currency" type="string" use="required"/>
     <attribute name="amount" type="float" use="required"/>
     <attribute name="decimalPower" type="Integer" default="0"/>
    </complexType>

    <element name="ValidPeriod" type="gvl:ValidPeriodType"/>
    <complexType name="ValidPeriodType">
      <attribute name="start" type="dateTime"/>
      <attribute name="end" type="dateTime"/>
    </complexType>

    <element name="Merchandise" type="gvl:MerchandiseType"/>
    <complexType name="MerchandiseType" mixed="true">
     <sequence>
      <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
    </complexType>

    <element name="Conditions" type="gvl:ConditionsType"/>
    <complexType name="ConditionsType" mixed="true">
     <sequence>
      <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
    </complexType>

   </schema>

8. VTS Schema Example

   An example of the schema definition for a VTS implementation is
   described below:

   <?xml version="1.0"?>
   <schema
    targetNamespace="http://www.example.com/vts"
    xmlns:vts="http://www.example.com/vts"
    xmlns="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified">

    <element name="Version" type="string"/>
    <element name="KeyInfo" type="hexBinary"/>

   </schema>

   Using this schema definition, the <vts:Version> can be used for
   specifying the VTS version number and the <vts:KeyInfo> element can
   be used for specifying the Issuer in the Voucher Component as shown
   in Section 5.

9. Security Considerations

   Security issues for delivering Voucher Components are discussed in
   Section 3.

10. Acknowledgement
    (tbs)

11. References

   [ECML] J. W. Parsons, "Electronic Commerce Modeling Language (ECML)
   Version 2 Specification", draft-ietf-trade-ecml2-spec-00.txt,
   February 2001.

   [GVT] K. Fujimura, "Requirements for Generic Voucher Trading",
   draft-ietf-trade-drt-requirements-02.txt, February 2001.

   [IPSEC] R. Thayer, N. Doraswamy, and R. Glenn, "IP Security Document
   Roadmap", RFC2411, November 1998

   [ISO4217] "Codes for the representation of currencies and funds",
   ISO 4217, 1995.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246,
   January 1999.

   [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A
   W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000.

   [XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature
   Syntax and Processing", draft-ietf-xmldsig-core-2-00.txt, April
   2001.

   [XML-ns] "Namespaces in XML", A W3C Recommendation,
   <http://www.w3.org/TR/REC-xml-names>, January 1999.

   [XML-Schema-1] H. Thompson, D. Beech, M. Maloney, and
   N. Mendelsohn, "XML Schema Part 1: Structures W3C Recommendation.",
   <http://www.w3.org/TR/xmlschema-1/>, May 2001.

   [XML-Schema-2] P. Biron and A Malhotra, "XML Schema Part 2:
   Datatypes W3C Recommendation.",
   <http://www.w3.org/TR/xmlschema-2/>, May 2001.

12. Author's Address

   Ko Fujimura and Masayuki Terada
   NTT Corporation
   1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN
   Phone: +81-(0)468-59-3814
   Fax:   +81-(0)468-59-2241
   Email: fujimura@isl.ntt.co.jp, terada@isl.ntt.co.jp