draft-ietf-trade-voucher-lang-00.txt   draft-ietf-trade-voucher-lang-01.txt 
Trade Working Group February 2001 Trade Working Group May 2001
INTERNET-DRAFT Ko Fujimura INTERNET-DRAFT Ko Fujimura
Masayuki Terada Masayuki Terada
Expires: August 2001 NTT Expires: November 2001 NTT
XML Voucher: Generic Voucher Language XML Voucher: Generic Voucher Language
<draft-ietf-trade-voucher-lang-00.txt> <draft-ietf-trade-voucher-lang-01.txt>
Status of This Document Status of This Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Please send comments to Distribution of this document is unlimited. Please send comments to
the TRADE working group at <ietf-trade@lists.elistx.com>, which may the TRADE working group at <ietf-trade@lists.elistx.com>, which may
be joined by sending a message with subject "subscribe" to <ietf- be joined by sending a message with subject "subscribe" to <ietf-
trade-request@lists.elistx.com>. trade-request@lists.elistx.com>.
Discussions of the TRADE working group are archived at Discussions of the TRADE working group are archived at
http://www.elistx.com/archives/ietf-trade. http://lists.elistx.com/archives/ietf-trade.
Abstract Abstract
This document specifies rules for defining voucher properties in This document specifies rules for defining voucher properties in XML
XML syntax. A voucher is a logical entity that represents a right syntax. A voucher is a logical entity that represents a right to
to claim goods or services. A voucher can be used to transfer a claim goods or services. A voucher can be used to transfer a
wide-range of electronic-values, including coupons, tickets, wide-range of electronic-values, including coupons, tickets, loyalty
loyalty points, and gift certificates, which are often necessary to points, and gift certificates, which are often necessary to process
process in the course of payment and/or delivery transactions. in the course of payment and/or delivery transactions.
Table of Contents Table of Contents
Status of this Memo ..............................................1 Status of this Memo ...............................................1
Abstract .........................................................1 Abstract ..........................................................1
1. Introduction ..................................................2 1. Introduction ...................................................2
2. Processing Model ..............................................2 2. Processing Model ...............................................3
3. Trust Model ...................................................3 3. Trust Model ....................................................4
4. Component Structure ...........................................4 4. Component Structure ............................................4
4.1 Voucher Component .........................................4 4.1 Voucher Component ..........................................4
4.2 Promise Component .........................................4 4.2 Promise Component ..........................................5
5. Syntax Overview and Examples ..................................6 5. Syntax Overview and Examples ...................................7
6. Semantics .....................................................7 6. Syntax and Semantics ...........................................8
7. DTD ...........................................................7 6.1 <Voucher> ..................................................8
8. Security Considerations .......................................7 6.2 <Provider> .................................................8
9. Acknowledgments ...............................................7 6.3 <Issuer> ...................................................9
10. References ....................................................7 6.4 <Promise> ..................................................9
11. Author's Address ..............................................8 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. Schemas .......................................................14
8. VTS Schema Example ............................................16
9. Security Considerations .......................................17
10. Acknowledgments ...............................................17
11. References ....................................................17
12. Author's Address ..............................................17
1. Introduction 1. Introduction
This document, XML Voucher, specifies rules for defining voucher This document, XML Voucher, specifies rules for defining voucher
properties in XML syntax. The motivation and background of the properties in XML syntax. The motivation and background of the
specification is described in [GVT]. specification are described in [GVT].
A voucher is a logical entity that represents a certain right and A voucher is a logical entity that represents a certain right and
logically managed by the Voucher Trading System (VTS). A voucher is is logically managed by the Voucher Trading System (VTS). A voucher
generated by the issuer, and traded among users, and finally is is generated by the issuer, traded among users, and finally
collected by the collector using VTS. collected by the collector using VTS.
This document defines syntax and semantics of the Voucher Component This document defines the syntax and semantics of Voucher
that is used to define voucher meaning and processing rules in XML Component, which defines voucher meaning and processing rules in
syntax [XML]. In a Voucher Component, properties needed to allow XML syntax [XML]. A Voucher Component defines the properties that
the voucher to be processed by VTS or other trading systems, e.g., must be satisfied to allow the voucher to be processed by VTS or
wallet or merchant system, are described. VTS definitions and other trading systems, e.g., wallet or merchant system. VTS
models are also defined in [GVT]. definitions and models are also defined in [GVT].
Note: This document uses a "voucher" as an "instance of voucher" Note: This document uses "voucher" as an "instance of voucher"
whose meaning is defined by Voucher Component. In other words, whose meaning is defined by Voucher Component. In other words,
multiple vouchers can be issued and managed by the VTS using the multiple vouchers can be issued and managed by the VTS using the
same Voucher Component. same Voucher Component.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC 2119] this document are to be interpreted as described in [RFC 2119]
2. Processing Model 2. Processing Model
There are several ways of implementing VTS and technologies are There are several ways of implementing VTS and technologies are
continuously changing. For discount coupons or event tickets, for continually changing. For discount coupons or event tickets, for
example, the smart-card-based offline VTS is often preferred, example, the smart-card-based offline VTS is often preferred,
whereas for bonds or securities, the centralized online VTS is whereas for bonds or securities, the centralized online VTS is
preferred. It is impractical to define standard protocols for preferred. It is impractical to define standard protocols for
issuing, transferring, or redeeming vouchers at this moment. issuing, transferring, or redeeming vouchers at this moment.
To provide implementation flexibility, this document assumes a To provide implementation flexibility, this document assumes a
modular wallet architecture that allows multiple VTS to be added as modular wallet architecture that allows multiple VTS to be added as
plug-ins. In the architecture, instead of specifying a standard plug-ins. In this architecture, instead of specifying a standard
voucher transfer protocol, two specifications, i.e., Voucher voucher transfer protocol, two specifications, i.e., Voucher
Component and VTS API specifications, are standardized (Figure 1). Component and VTS API specifications, are standardized (Figure 1).
Sender wallet/Issuing system Receiver wallet/Collecting system Sender wallet/Issuing system Receiver wallet/Collecting system
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
| | | | | | | |
| | Voucher Component | | | | Voucher Component | |
| | (Specifies Issuer, Promise, Holder, and VTS Provider) | | | | (Specifies Issuer, Promise, Holder, and VTS Provider) | |
| |-------------------------------------------------------->| | | |-------------------------------------------------------->| |
| | | | | | | | | | | |
| | Intention to receive and payment (option) | | | | Intention to receive and payment (option) | |
| |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | | | |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | |
| | | | | | | | | | | |
| | | | | |
| | Issue/transfer/ VTS | | VTS Register | | | | Issue/transfer/ VTS | | VTS Register | |
| | redeem request plug-in | plug-in request | | | | redeem request plug-in | plug-in Listener(*1)| |
| |------------------>| | | |<------------------| | | |------------------>| | | |<------------------| |
| | (VTS API) |<- - - - - - - ->| (VTS API) | | | | (VTS API) |<- - - - - - - ->| (VTS API) | |
| | | VTS-specific | | | | | | VTS-specific | | |
| | | protocol if VTS | | | | | | protocol if VTS | | |
| | | is distributed | | | | | | is distributed | | |
| | Event |<- - - - - - - ->| Event | | | | Result |<- - - - - - - ->| Notify(*2) | |
| |<------------------| | | |------------------>| | | |<------------------| | | |------------------>| |
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
Figure 1. Wallet architecture with VTS plug-ins (*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 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 and which VTS is to be used, the issuing system or wallet system
requests the corresponding VTS plug-in to permit the issue, requests the corresponding VTS plug-in to permit the issue,
transfer, or redeem transactions to be performed via the VTS transfer, or redeem transactions to be performed via the VTS
API. The VTS then rewrites the ownership of the vouchers using a API. The VTS then rewrites the ownership of the vouchers using the
VTS-specific protocol. Finally, a completion event is sent to the VTS-specific protocol. Finally, a completion event is sent to the
wallet systems or issuing/collecting systems. 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 3. Trust Model
A voucher is trusted if the issuer and VTS provider are trusted, A voucher is trusted if the Issuer and VTS Provider are trusted,
since the issuer is responsible for the contents of the voucher and since the Issuer is responsible for the contents of the voucher and
the VTS provider is responsible for preventing ownership from being the VTS Provider is responsible for preventing ownership from being
assigned to multiple users. This model enables trading partners to assigned to multiple users.
verify the trust of the voucher regardless of the trust of the
partners.
The trust level required for issuer and VTS provider depends on the The trust level required for Issuer and VTS Provider depends on the
type (or Promise) of the voucher. To provide the information needed type (or Promise) of the voucher. To provide the information needed
for the verification, the conditions of issuer and VTS provider are for verification, the conditions of Issuer and VTS Provider are
specified in the Voucher Component. 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. This model
enables trading partners to verify their trust in the voucher
regardless of their trust in the partners.
In this case, however, if a malicious user could alter the Voucher This document assumes that the Voucher Component is the root of
Component, a forged voucher, would be verified as valid. This trust. If a malicious user could alter the Voucher Component, a
document, therefore, assumes that such alteration is impossible forged voucher could be verified as valid.
during delivery of the Voucher Component; this is possible with
existing technologies, such as [XMLDSIG] or [TLS]. The Voucher Component is usually delivered from the trusted VTS
Provider, Issuer or trusted third party using a secure
communication channel, such as [XMLDSIG], [TLS], or
[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 Note: The Voucher Component does not have to be sent from the
sender of the voucher. It can be directly delivered from the sender of the voucher. Note also that a set of trusted Voucher
trusted issuer or trusted third party using TLS or other secure Components can be downloaded before conducting a transaction.
communication channel. Note also that a set of trusted Voucher
Components can be pre-downloaded before conducting a transaction.
4. Component Structure 4. Component Structure
4.1 Voucher Component 4.1 Voucher Component
A Voucher Component provides VTS branding information, and basic A Voucher Component provides VTS Provider information, and basic
properties for representing a voucher, i.e., issuer, promise, and properties for representing a voucher, i.e., Issuer, Promise, and
holder. Implementation-specific properties are often required for Holder. Implementation-specific properties are often required for
authenticating issuer and holder. These implementation-specific authenticating VTS Provider, Issuer and Holder. These
properties of the VTS can be attached as child elements using implementation-specific properties of the VTS can be attached as
[XML-ns]. child elements using [XML-ns].
The Voucher Component contains Provider Component, Issuer The Voucher Component contains Provider Component, Issuer
Component, Promise Component, and Holder Component as follows: Component, Promise Component, and Holder Component as follows:
Provider Component Provider Component
Provides properties to specify which VTS Provider (or VTS Provides properties that specify which VTS Provider (or VTS
plug-in) can be used for trading the voucher. plug-in) can be used for trading the voucher.
Issuer Component Issuer Component
Provides properties specifying the issuer of the vouchers. This Provides properties specifying the Issuer of the vouchers. This
is optional and can be omitted if the issuer role is delegated to is optional and can be omitted if the Issuer role is delegated to
the VTS Provider. the VTS Provider.
Promise Component Promise Component
Provides properties used by the application system of VTS, e.g., Provides properties used by the application system of VTS, e.g.,
wallet system, merchant system. The Promise Component is wallet system, merchant system. The Promise Component is
transparent to the VTS and is described in Section 4.2. transparent to the VTS and is described in Section 4.2.
Holder Component Holder Component
Provides properties to specify the holder of the vouchers. This Provides properties that specify the Holder of the vouchers. This
is optional and can be omitted if the vouchers are is optional and can be omitted if the vouchers are transferable.
transferable. (Note: Even for transferable vouchers, this
component may be used by the VTS depending on the
implementation.)
4.2 Promise Component 4.2 Promise Component
The Promise Component provides common properties useful for The Promise Component provides the information needed to identify
displaying and manipulating wallet systems. It includes monetary the monetary value or merchandize rendered when the voucher is
property (value) of the voucher. These monetary properties are redeemed. It includes:
needed to calculate the amount paid when the vouchers are redeemed
at Merchant site, etc.
The Promise Component contains Title Component, Description o How much value/items can be claimed in exchange for the voucher
Component, ValidPeriod Component, Redemption Component, Merchandise
Component, and Value Component as follows: 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 the title and description of each voucher.
The Promise Component contains the Title Component, Description
Component, Value Component, ValidPeriod Component, Merchandise
Component, and Condition Component as follows:
Title Component Title Component
Provides the title of the voucher. This is mainly for displaying Provides the title of the voucher. This is mainly for listing
the list of entities stored in a wallet system. the entities stored in a wallet system.
Description Component Description Component
Provides a short description of the voucher. This is mainly for Provides a short description of the voucher. This is mainly for
displaying the entities stored in a wallet system. listing the entities stored in a wallet system.
ValidPeriod Component Value Component
Indicates voucher's validity period, start date and end date. Provides the value of each voucher. There are two types of
values, i.e., fixed and 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.
Redemption Component The Value Component also indicates the number of vouchers to be
redeemed for claiming the merchandise or monetary value specified
in Merchandise Component or Value Component. If "n"(>0) is
specified, the merchandize or monetary value can be claimed in
exchange for "n sheets of" vouchers. If "0" is specified, it
can be used repeatedly.
Provides the number of vouchers to be redeemed for claiming the ValidPeriod Component
merchandise or financial value specified in Merchandise Component
or Value Component. If "n" (>0) is specified, the merchandize can Provides restrictions on the validity period of the voucher,
be claimed in exchange with "n sheets of" vouchers. (Note: i.e., start date and end date.
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 can be used repeatedly regardless of the number of
times redeemed.
Merchandise Component Merchandise Component
Provides domain-specific meaning of the voucher, e.g., reference Provides restrictions on the object to be claimed.
number of the merchandize or seat number for an event ticket, Domain-specific meaning of the voucher, e.g., reference number of
which is needed to identify the merchandize rendered when the the merchandize or seat number for an event ticket, is specified
voucher is redeemed. The properties of this component are left to to identify the merchandize rendered when the voucher is
the other domain-specific specifications and out of scope of this redeemed.
document. Domain-specific properties can be attached as child
elements using [XML-ns].
Value Component Condition Component
Provides the value of the vouchers. There are two types of Provides any other applicable restrictions. This is intended to
values, i.e., fixed and ratio values. For a fixed value, the cover contracts between the issuer and holder of the
currency and amount of the value is specified. For a ratio value, voucher in natural language form.
the discount ratio of the price of the corresponding merchandize
is specified.
Using the above Components, monetary meaning for diverse types of Using the above Components, semantics for diverse types of vouchers
vouchers can be defined as shown in Table 1. can be defined as shown in Table 1.
+---------------+----------+---------------+---------------------+ +----------------+--------------------------------+---------------+
| |Number | | Value | | | Value | Restrictions |
| Examples |needed for| Merchandise +-----+---------------+ | +-----+---------------+----------+---------------+
| |redemption| |Ratio| Fixed | | Examples |Ratio| Fixed |Number | Merchandise |
| | | | |Amount Currency| | | +------+--------+Needed for| |
+---------------+----------+---------------+-----+------+--------+ | | |Amount|Currency|redemption| |
|Gift certifiate| 1 |(Not specified)| | 25 | USD | +----------------+-----+------+--------+----------+---------------+
|Loyalty point | 20 |(Not specified)| | 200 | AUD | |Gift certificate| | 25 | USD | 1 |(Not specified)|
|Member card | 0 |(Not specified)| 0.2| | | |Loyalty point | | 200 | AUD | 20 |(Not specified)|
|Coupon | 1 |Beef 500g | 0.3| | | |Member card | 20%| | | 0 |(Not specified)|
|Event ticket | 1 |Hall A, S ,K23 | 1.0| | | |Coupon | 30%| | | 1 |Beef 500g |
|Exchange ticket| 1 |ISBN:0071355014| 1.0| | | |Event ticket | 100%| | | 1 |Hall A, S ,K23 |
+---------------+----------+---------------+-----+------+--------+ |Exchange ticket | 100%| | | 1 |ISBN:0071355014|
+----------------+-----+------+--------+----------+---------------+
Table 1. Examples of vouchers and their properties Table 1. Examples of vouchers and their properties
5. Syntax Overview and Examples 5. Syntax Overview and Examples
This section provides an overview and examples of Voucher This section provides an overview and examples of Voucher
Component. The formal syntax and semantics are found in Sections 6 Component. The formal syntax and semantics are found in Sections 6
and 7. and 7.
Voucher Components are represented by the <Voucher> element which Voucher Components are represented by the <Voucher> element which
has the following structure (where "?" denotes zero or one has the following structure (where "?" denotes zero or one
occurrence; "+" denotes one or more occurrences; and "*" denotes occurrence):
zero or more occurrences):
<Voucher> <Voucher>
(Provider) (Provider)
(Issuer)? (Issuer)?
<Promise> <Promise>
(Title)? (Title)?
(Description)? (Description)?
(Value)
(ValidPeriod)? (ValidPeriod)?
(Redemption)? (Merchandise)?
(Value)? (Conditions)?
(Merchandise)+
</Promise> </Promise>
(Holder)? (Holder)?
</Voucher> </Voucher>
An example of a Voucher Component is described below. This is an An example of a Voucher Component is described below. This is an
example of a five dollar discount coupon for specific merchandize, example of a five dollar discount coupon for specific merchandize,
a book with ISBN number 0071355014. The coupon is valid from April 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 1st in 2001 to March 31st in 2002. To claim this offer, one voucher
must be spent. must be spent.
<?xml version="1.0"?> <?xml version="1.0"?>
<Voucher xmlns="http://www.ietf.org/rfc/rfcXXXX.txt" <Voucher xmlns="http://www.ietf.org/rfc/rfcXXXX"
xmlns:vts="http://www.example.com/vts.txt"> xmlns:vts="http://www.example.com/vts">
<Provider Name="Voucher Wallet 2001"> <Provider name="Voucher Wallet 2001">
<vts:KeyInfo>...</vts:KeyInfo> <vts:Version>2.31</vts:Version>
</Provider> </Provider>
<Issuer Name="Alice Book Center, Ltd."> <Issuer name="Alice Book Center, Ltd.">
<vts:KeyInfo>...</vts:KeyInfo> <vts:KeyInfo>1DA8DFCF95521014BBB7171B95545E8D61AE803F
</vts:KeyInfo>
</Issuer> </Issuer>
<Promise> <Promise>
<Title>IOTP Book Coupon</Title> <Title>IOTP Book Coupon</Title>
<Description>$5 off IOTP Book</Description> <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"/> <ValidPeriod start="2001-04-01" end="2002-03-31"/>
<Redemption spend="1"/> <Merchandise>
<Value currency="USD" amount="5"/> <bk:BookID xmlns:bk="http://www.example.com/book"
<Merchandise xmlns="http://www.example.com/book.txt"> bk:ISDN="0071355014"/>
<BookID ISBN="0071355014"/>
</Merchandise> </Merchandise>
<Conditions>It can be claimed only at Alice Book Center.
</Conditions>
</Promise> </Promise>
</Voucher> </Voucher>
6. Semantics 6. Syntax and Semantics
(tbs)
7. DTD The general structure of an XML voucher is described in Component
(tbs) Structure (section 4). This section details the Voucher Component
features. Features described in this section MUST be implemented
unless otherwise indicated. The syntax is defined via
[XML-Schema-1] [XML-Schema-2]. For clarity, unqualified elements in
schema definitions are in the XML schema namespace:
8. Security Considerations xmlns="http://www.w3.org/2001/XMLSchema"
References to the XML Voucher schema defined herein use the prefix
"gvl" and are in the namespace:
xmlns:gvl="http://www.ietf.org/rfc/rfcXXXX.txt"
This namespace is also used for unqualified elements in 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 Security issues for delivering Voucher Components are discussed in
Section 3. Security is a major issue in implementing VTS. For XML Section 3.
Voucher, however, the only requirements for achieving security are
to provide the parameters needed for establishing security.
9. Acknowledgement 10. Acknowledgement
(tbs) (tbs)
10. References 11. References
[ECML] ECML Version 2, to appear. [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", [GVT] K. Fujimura, "Requirements for Generic Voucher Trading",
draft-ietf-trade-drt-requirements-02.txt, February 2001. draft-ietf-trade-drt-requirements-02.txt, February 2001.
[IOTP] D. Burdett, "The Internet Open Trading Protocol", RFC2801, [IPSEC] R. Thayer, N. Doraswamy, and R. Glenn, "IP Security Document
April 2000. 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 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246,
January 1999. January 1999.
[XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A
W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000. W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000.
[XMLDSIG] "XML-Signature Syntax and Processing", [XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature
draft-ietf-xmldsig- core-11.txt, in RFC Editor queue for Syntax and Processing", draft-ietf-xmldsig-core-2-00.txt, April
publication as Proposed Standard. 2001.
[XML-ns] "Namespaces in XML", A W3C Recommendation, [XML-ns] "Namespaces in XML", A W3C Recommendation,
<http://www.w3.org/TR/REC-xml-names>, January 1999. <http://www.w3.org/TR/REC-xml-names>, January 1999.
11. Authors Address [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 Ko Fujimura and Masayuki Terada
NTT Corporation NTT Corporation
1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN
Phone: +81-(0)468-59-3814 Phone: +81-(0)468-59-3814
Fax: +81-(0)468-59-2241 Fax: +81-(0)468-59-2241
Email: fujimura@isl.ntt.co.jp, terada@isl.ntt.co.jp Email: fujimura@isl.ntt.co.jp, terada@isl.ntt.co.jp
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/