4153
INFORMATIONAL
XML Voucher: Generic Voucher Language
Authors: K. Fujimura, M. Terada, D. Eastlake 3rd
Date: September 2005
Area: app
Working Group: trade
Stream: IETF
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 often have to be processed in the course of payment and/or delivery transactions. This memo provides information for the Internet community.
RFC 4153
INFORMATIONAL
Network Working Group K. Fujimura
Request for Comments: 4153 NTT
Category: Informational M. Terada
NTT DoCoMo
D. Eastlake 3rd
Motorola Laboratories
September 2005
<span class="h1">XML Voucher: Generic Voucher Language</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 often have to be processed in
the course of payment and/or delivery transactions.
Table of Contents
<a href="#section-1">1</a>. Introduction ................................................. <a href="#page-2">2</a>
<a href="#section-2">2</a>. Processing Model ............................................. <a href="#page-2">2</a>
<a href="#section-3">3</a>. Trust Model .................................................. <a href="#page-4">4</a>
<a href="#section-4">4</a>. Component Structure .......................................... <a href="#page-4">4</a>
<a href="#section-5">5</a>. Syntax Overview and Examples ................................. <a href="#page-6">6</a>
<a href="#section-6">6</a>. Syntax and Semantics ......................................... <a href="#page-8">8</a>
<a href="#section-6.1">6.1</a>. <Voucher> ............................................... <a href="#page-8">8</a>
<a href="#section-6.2">6.2</a>. <Title> ................................................. <a href="#page-9">9</a>
<a href="#section-6.3">6.3</a>. <Description> ........................................... <a href="#page-9">9</a>
<a href="#section-6.4">6.4</a>. <Provider> .............................................. <a href="#page-9">9</a>
<a href="#section-6.5">6.5</a>. <Issuer> ................................................ <a href="#page-10">10</a>
<a href="#section-6.6">6.6</a>. <Holder> ................................................ <a href="#page-10">10</a>
<a href="#section-6.7">6.7</a>. <Collector> ............................................. <a href="#page-11">11</a>
<a href="#section-6.8">6.8</a>. <Value> ................................................. <a href="#page-11">11</a>
<a href="#section-6.8.1">6.8.1</a>. <Ratio> .......................................... <a href="#page-13">13</a>
<a href="#section-6.8.2">6.8.2</a>. <Fixed> .......................................... <a href="#page-13">13</a>
<span class="grey">Fujimura, et al. Informational [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
<a href="#section-6.9">6.9</a>. <Merchandise> ........................................... <a href="#page-14">14</a>
<a href="#section-6.10">6.10</a>. <ValidPeriod> .......................................... <a href="#page-14">14</a>
<a href="#section-6.11">6.11</a>. <Conditions> ........................................... <a href="#page-15">15</a>
<a href="#section-7">7</a>. IANA Considerations .......................................... <a href="#page-15">15</a>
<a href="#section-8">8</a>. VTS Schema Example ........................................... <a href="#page-18">18</a>
<a href="#section-9">9</a>. Security Considerations ...................................... <a href="#page-18">18</a>
<a href="#section-10">10</a>. Acknowledgements ............................................. <a href="#page-19">19</a>
<a href="#section-11">11</a>. Normative References ......................................... <a href="#page-19">19</a>
<a href="#section-12">12</a>. Informative References ....................................... <a href="#page-20">20</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies rules for defining voucher properties in XML
syntax. The motivation and background of the specification are
described in [<a href="#ref-VTS" title=""Requirements and Design for Voucher Trading System (VTS)"">VTS</a>].
A voucher is a logical entity that represents a certain right and
that is logically managed by the Voucher Trading System (VTS). A
voucher is generated by the issuer, traded among users, and finally
collected by the collector using VTS.
This document defines the syntax and semantics of the Voucher
Component, which defines voucher meaning and processing rules in XML
syntax [<a href="#ref-XML" title=""Extensible Mark Up Language (XML) 1.0 (Second Edition)"">XML</a>]. A Voucher Component defines the properties that must
be satisfied to allow the voucher to be processed by VTS or other
trading systems; e.g., a wallet or merchant system. VTS definitions
and models are also defined in [<a href="#ref-VTS" title=""Requirements and Design for Voucher Trading System (VTS)"">VTS</a>].
Note: This document uses "voucher" as an "instance of voucher", whose
meaning is defined by the Voucher Component. In other words, a
Voucher Component is NOT a voucher, and 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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>]
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Processing Model</span>
There are several ways of implementing VTS and technologies are
continually changing. For discount coupons or event tickets, for
example, the smartcard-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 time.
<span class="grey">Fujimura, et al. Informational [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
To provide implementation flexibility, this document assumes a
modular wallet architecture that allows multiple VTSes to be added as
plug-ins. In this architecture, instead of specifying a standard
voucher transfer protocol, two specifications, Voucher Component and
VTS-API, are standardized (Figure 1).
After the sender and receiver agree on which 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 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 is defined in [<a href="#ref-VTS-API" title=""Voucher Trading System Application Programming Interface (VTS-API)"">VTS-API</a>].
Sender wallet/Issuing system Receiver wallet/Collecting system
+---------------------------+ +---------------------------+
| | | |
| | Voucher Component | |
| | (Specifies VTS Provider and Promise) | |
| |-------------------------------------------------------->| |
| | | | | |
| | Intention to receive and payment (option) | |
| |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | |
| | | | | |
| | | | | |
| | Issue/transfer/ VTS | | VTS Register | |
| | redeem request plug-in | plug-in Listener(*1)| |
| |------------------>| | | |<------------------| |
| | (VTS-API) |<- - - - - - - ->| (VTS-API) | |
| | | VTS-specific | | |
| | | protocol if VTS | | |
| | | is distributed | | |
| | Result |<- - - - - - - ->| 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
<span class="grey">Fujimura, et al. Informational [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Trust Model</span>
A voucher is trusted if the Issuer and VTS Provider are trusted, as
the Issuer is responsible for the contents of the voucher and the VTS
Provider is responsible for preventing ownership from being assigned
to multiple users.
The trust level required for the Issuer and VTS Provider depends on
the type (or Promise) of the voucher. To provide the information
needed for verification, the conditions of the Issuer and VTS
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. 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 could be verified as valid.
When a Voucher Component is delivered from the trusted VTS Provider,
Issuer, or trusted third party, a secure communication channel (e.g.,
[<a href="#ref-TLS" title=""The TLS Protocol Version 1.0"">TLS</a>], [<a href="#ref-IPSEC" title=""IP Security Document Roadmap"">IPSEC</a>], or object security, such as [<a href="#ref-XMLDSIG" title=""(Extensible Markup Language) XML-Signature Syntax and Processing"">XMLDSIG</a>]) should be used
to prevent alteration during the delivery.
Note: The Voucher Component does not have to be sent from the sender
of the voucher. Note also that a set of trusted Voucher Components
can be downloaded before a transaction is conducted.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Component Structure</span>
The Voucher 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,
and
o restrictions applied to the voucher
- participants (VTS Provider, Issuer, Holder, and Collector),
- objects (merchandise) to be claimed,
- time when valid (validity period), and
- others.
<span class="grey">Fujimura, et al. Informational [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
The Voucher 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 Voucher Component contains the following components:
Title Component
Provides the title of the voucher. This is mainly for listing the
entities stored in a wallet system.
Description Component
Provides a short description of the voucher. This is mainly for
listing the entities stored in a wallet system.
Provider Component
Provides restrictions on which VTS Provider (or VTS plug-in) can
be used for trading the voucher.
Issuer Component
Provides restrictions on the Issuer of the voucher.
Holder Component
Provides restrictions on the Holder of the voucher.
Collector Component
Provides restrictions on the Collector of the voucher.
Value Component
Provides the value of each voucher. There are two types of
values: 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.
The Value Component also indicates the number of vouchers to be
redeemed for claiming the merchandise or monetary value specified
in the 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.
<span class="grey">Fujimura, et al. Informational [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
Merchandise Component
Provides restrictions on the object to be claimed. The domain-
specific meaning of the voucher (e.g., reference number of the
merchandize or seat number for an event ticket) is specified to
identify the merchandize rendered when the voucher is redeemed.
ValidPeriod Component
Provides restrictions on the validity period of the voucher; i.e.,
start date and end date.
Condition Component
Provides any other applicable restrictions. This is intended to
cover contracts between the issuer and holder of the voucher in
natural language form.
Using the above Components, semantics for diverse types of vouchers
can be defined as shown in Table 1.
+----------------+--------------------------------+---------------+
| | Value | Restrictions |
| +-----+---------------+----------+---------------+
| Examples |Ratio| Fixed |Number | Merchandise |
| | +------+--------+needed for| |
| | |Amount|Currency|redemption| |
+----------------+-----+------+--------+----------+---------------+
|Gift certificate| | 25 | USD | 1 |(Not specified)|
|Loyalty point | | 1 | AUD | 10 |(Not specified)|
|Member card | 20%| | | 0 |(Not specified)|
|Coupon | 30%| | | 1 |Beef 500g |
|Event ticket | 100%| | | 1 |Hall A, S ,K23 |
|Exchange ticket | 100%| | | 1 |ISBN:0071355014|
+----------------+-----+------+--------+----------+---------------+
Table 1. Examples of vouchers and their properties
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Syntax Overview and Examples</span>
This section provides an overview and examples of Voucher Components.
The formal syntax and semantics are found in Sections <a href="#section-6">6</a> and <a href="#section-7">7</a>.
Voucher Components are represented by the <Voucher> element, which
has the following structure (where "?" denotes zero or one
occurrence):
<span class="grey">Fujimura, et al. Informational [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
<Voucher>
(Title)
(Description)?
(Provider)
(Issuer)?
(Holder)?
(Collector)?
(Value)
(Merchandise)?
(ValidPeriod)?
(Conditions)?
</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 1,
2001, to March 31, 2002. To claim this offer, one voucher must be
spent.
<?xml version="1.0" encoding="UTF-8"?>
<Voucher xmlns="urn:ietf:params:xml:ns:vts-lang"
xmlns:vts="http://www.example.com/vts">
<Title>IOTP Book Coupon</Title>
<Description>$5 off IOTP Book</Description>
<Provider name="Voucher Exchanger 2002">
<vts:Version>VE2.31</vts:Version>
</Provider>
<Issuer name="Alice Book Center, Ltd.">
<vts:KeyInfo>
1DA8DFCF95521014BBB7171B95545E8D61AE803F
</vts:KeyInfo>
</Issuer>
<Collector name="Alice Book Center, Ltd."/>
<Value type="discount" spend="1">
<Fixed amount="5" currency="USD"/>
</Value>
<Merchandise>
<bk:Book xmlns:bk="http://www.example.com/bk"
bk:isbn="0071355014"/>
</Merchandise>
<ValidPeriod start="2002-04-01" end="2003-03-31"/>
<Conditions>
The value of this coupon is subject to tax.
</Conditions>
</Voucher>
<span class="grey">Fujimura, et al. Informational [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Syntax and Semantics</span>
The general structure of an XML Voucher Component is described in
<a href="#section-4">Section 4</a>. This section details the Voucher Component features.
Features described in this section MUST be implemented unless
otherwise indicated. The syntax is defined via [<a href="#ref-XML-Schema-1" title=""XML Schema Part 1: Structures W3C Recommendation."">XML-Schema-1</a>]
[<a href="#ref-XML-Schema-2" title=""XML Schema Part 2: Datatypes W3C Recommendation."">XML-Schema-2</a>]. For clarity, unqualified elements in schema
definitions are in the XML schema namespace:
xmlns="http://www.w3.org/2001/XMLSchema"
References to XML Voucher schema defined herein use the prefix "gvl"
and are in the namespace:
xmlns:gvl="urn:ietf:params:xml:ns:vts-lang"
This namespace URI for elements defined by this document is a URN
[<a href="#ref-URN" title=""URN Syntax"">URN</a>] that uses the namespace identifier 'ietf', defined by
[<a href="#ref-URN-NS-IETF" title=""A URN Namespace for IETF Documents"">URN-NS-IETF</a>] and extended by [<a href="#ref-XML-Registry" title=""The IETF XML Registry"">XML-Registry</a>].
This namespace is also used for unqualified elements in voucher
examples.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. <Voucher></span>
The <Voucher> element contains <Title>, <Provider>, and <Value>
elements and optionally contains <Description>, <Issuer>, <Holder>,
<Collector>, <ValidPeriod>, and <Condition> 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:Title"/>
<element ref="gvl:Description" minOccurs="0"/>
<element ref="gvl:Provider"/>
<element ref="gvl:Issuer" minOccurs="0"/>
<element ref="gvl:Holder" minOccurs="0"/>
<element ref="gvl:Collector" minOccurs="0"/>
<element ref="gvl:Value"/>
<element ref="gvl:Merchandise" minOccurs="0"/>
<element ref="gvl:ValidPeriod" minOccurs="0"/>
<element ref="gvl:Conditions" minOccurs="0"/>
</sequence>
</complexType>
<span class="grey">Fujimura, et al. Informational [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. <Title></span>
The <Title> element contains a simpletext 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"/>
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. <Description></span>
The <Description> element contains a simpletext 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"/>
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. <Provider></span>
The <Provider> element may contain any element that is 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 (see Section 7 of [<a href="#ref-VTS-API" title=""Voucher Trading System Application Programming Interface (VTS-API)"">VTS-API</a>]). These implementation-
specific elements of the VTS can be extended using [<a href="#ref-XML-ns" title=""Namespaces in XML"">XML-ns</a>]. An
example of such a schema definition is described in <a href="#section-8">Section 8</a>.
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" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="string"/>
</complexType>
<span class="grey">Fujimura, et al. Informational [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. <Issuer></span>
The <Issuer> element may contain any element that is used to specify
or restrict the Issuer of the voucher.
The Issuer of the voucher is generally managed by the VTS [<a href="#ref-VTS-API" title=""Voucher Trading System Application Programming Interface (VTS-API)"">VTS-API</a>].
There is no need to specify the Issuer of the voucher using this
element if there are no restrictions on the Issuer.
An implementation of a VTS may use this element to describe the
authentication data and/or qualification information of the Issuer.
This implementation-specific information can be extended through
sub-elements using [<a href="#ref-XML-ns" title=""Namespaces in XML"">XML-ns</a>]. An example of such a schema definition
is described in <a href="#section-8">Section 8</a>.
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 <a href="#section-6.4">Section 6.4</a>.
If the <Issuer> element is omitted, it MUST be interpreted that there
are no restrictions on the Issuer.
<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>. <Holder></span>
The <Holder> element may contain any element that is used to specify
or restrict the Holder of the voucher.
The Holder of the voucher is generally managed by the VTS [<a href="#ref-VTS-API" title=""Voucher Trading System Application Programming Interface (VTS-API)"">VTS-API</a>].
There is no need to specify the Holder of the voucher using this
element if there are no restrictions on the Holder.
An implementation of a VTS may use this element to describe the
authentication data and/or qualification information of the Holder.
This implementation-specific information can be extended through
sub-elements using [<a href="#ref-XML-ns" title=""Namespaces in XML"">XML-ns</a>].
The <Holder> element has a string-type "name" attribute that is used
to specify the name of the Holder.
<span class="grey">Fujimura, et al. Informational [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
The <Holder> element is defined by the following schema:
<element name="Holder" type="gvl:RoleType"/>
The <RoleType> element type is defined in <a href="#section-6.4">Section 6.4</a>.
If the <Holder> element is omitted, it MUST be interpreted that there
are no restrictions on the Holder.
<span class="h3"><a class="selflink" id="section-6.7" href="#section-6.7">6.7</a>. <Collector></span>
The <Collector> element may contain any element that is used to
specify or restrict the Collector of the voucher.
There is no need to specify the Collector of the voucher using this
element if there are no restrictions on the Collector.
An implementation of a VTS may use this element to describe the
authentication data and/or qualification information of the
Collector. This implementation-specific information can be extended
through sub-elements using [<a href="#ref-XML-ns" title=""Namespaces in XML"">XML-ns</a>].
The <Collector> element has a string-type "name" attribute that is
used to specify the name of the Collector.
The <Collector> element is defined by the following schema:
<element name="Collector" type="gvl:RoleType"/>
The <RoleType> element type is defined in <a href="#section-6.4">Section 6.4</a>.
If the <Collector> element is omitted, it MUST be interpreted that
there are no restrictions on the Collector.
<span class="h3"><a class="selflink" id="section-6.8" href="#section-6.8">6.8</a>. <Value></span>
The <Value> element optionally contains a <Fixed> or <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.
<span class="grey">Fujimura, et al. Informational [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
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
the <Ratio> nor the <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.
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.
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 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 or the whole element is omitted, it MUST be
interpreted that "1" 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>
<span class="grey">Fujimura, et al. Informational [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
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>
<span class="h4"><a class="selflink" id="section-6.8.1" href="#section-6.8.1">6.8.1</a>. <Ratio></span>
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 following schema:
<complexType name="RatioValueType">
<attribute name="percentage" use="required">
<simpleType>
<restriction base="float">
<maxInclusive value="100"/>
</restriction>
</simpleType>
</attribute>
</complexType>
<span class="h4"><a class="selflink" id="section-6.8.2" href="#section-6.8.2">6.8.2</a>. <Fixed></span>
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 [<a href="#ref-ISO4217" title=""Codes for the representation of currencies and funds"">ISO4217</a>]. For example, US dollars 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.
<span class="grey">Fujimura, et al. Informational [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
For example, with a dollar currency denominated in cents, "1" is
specified 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 follows:
<complexType name="FixedValueType">
<attribute name="currency" type="string" use="required"/>
<attribute name="amount" type="float" use="required"/>
<attribute name="decimalPower" type="short" default="0"/>
</complexType>
<span class="h3"><a class="selflink" id="section-6.9" href="#section-6.9">6.9</a>. <Merchandise></span>
The <Merchandise> element may contain any element 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 [<a href="#ref-XML-ns" title=""Namespaces in XML"">XML-ns</a>].
This element is intended to be interpreted by a collecting system.
An implementation of a wallet system does not have to use this
element. Any restrictions applied should also be described in the
<Description> element or the <Conditions> elements in natural
language form to enable users to check the restrictions.
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>
<span class="h3"><a class="selflink" id="section-6.10" href="#section-6.10">6.10</a>. <ValidPeriod></span>
The <ValidPeriod> 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.
<span class="grey">Fujimura, et al. Informational [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
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 that specified by the end
attribute (inclusive). 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.
<span class="h3"><a class="selflink" id="section-6.11" href="#section-6.11">6.11</a>. <Conditions></span>
The <Conditions> element contains any other restrictions or
conditions applied. This is intended to cover contracts between the
issuer and the holder of the voucher in natural language form.
An implementation of a wallet system SHOULD provide a means of
displaying the text in this element.
The <Conditions> element has no attribute.
The <Conditions> element is defined by the following schema:
<element name="Conditions" type="string"/>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [<a href="#ref-XML-Registry" title=""The IETF XML Registry"">XML-Registry</a>]. IANA
has registered two URI assignments.
Registration request for the vts-lang namespace:
URI: urn:ietf:params:xml:ns:vts-lang
Registrant Contact: See the "Authors' Addresses" section of this
document.
XML: None. Namespace URIs do not represent an XML specification.
<span class="grey">Fujimura, et al. Informational [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
Registration request for the vts-lang XML schema:
URI: urn:ietf:params:xml:schema:vts-lang
Registrant Contact: See the "Authors' Addresses" section of this
document.
XML:
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:ietf:params:xml:ns:vts-lang"
xmlns:gvl="urn:ietf:params:xml:ns:vts-lang"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<element name="Voucher" type="gvl:VoucherType"/>
<complexType name="VoucherType">
<sequence>
<element ref="gvl:Title"/>
<element ref="gvl:Description" minOccurs="0"/>
<element ref="gvl:Provider"/>
<element ref="gvl:Issuer" minOccurs="0"/>
<element ref="gvl:Holder" minOccurs="0"/>
<element ref="gvl:Collector" minOccurs="0"/>
<element ref="gvl:Value"/>
<element ref="gvl:Merchandise" minOccurs="0"/>
<element ref="gvl:ValidPeriod" minOccurs="0"/>
<element ref="gvl:Conditions" minOccurs="0"/>
</sequence>
</complexType>
<element name="Title" type="string"/>
<element name="Description" type="string"/>
<element name="Provider" type="gvl:RoleType"/>
<element name="Issuer" type="gvl:RoleType"/>
<element name="Holder" type="gvl:RoleType"/>
<element name="Collector" type="gvl:RoleType"/>
<complexType name="RoleType" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="string"/>
</complexType>
<span class="grey">Fujimura, et al. Informational [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
<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="short" default="0"/>
</complexType>
<element name="Merchandise" type="gvl:MerchandiseType"/>
<complexType name="MerchandiseType" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="ValidPeriod" type="gvl:ValidPeriodType"/>
<complexType name="ValidPeriodType">
<attribute name="start" type="dateTime"/>
<span class="grey">Fujimura, et al. Informational [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
<attribute name="end" type="dateTime"/>
</complexType>
<element name="Conditions" type="string"/>
</schema>
END
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. VTS Schema Example</span>
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 <a href="#section-5">Section 5</a>.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
The VTS must provide a means to prevent forgery, alteration,
duplicate-redemption, reproduction of a voucher, and non-repudiation
of transactions, as described in Section 3.2 of [<a href="#ref-VTS" title=""Requirements and Design for Voucher Trading System (VTS)"">VTS</a>]. This will
commonly require the presence of a unique serial number or the like
in each Voucher instance, usually outside the Voucher Component.
These security requirements, however, mainly follow the VTS plug-ins
and their protocols. This document assumes that the VTS plug-ins are
trusted and are installed by some means; e.g., manually checked as
are other download applications.
The Voucher Component, however, defines restrictions on the VTS
Provider (or VTS plug-in), and, if this information is altered,
incorrect VTS plug-ins not accepted by the issuer could be used,
allowing a forged voucher to be verified as if it were valid. To
prevent this situation, the Voucher Component should be stored and
<span class="grey">Fujimura, et al. Informational [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
acquired securely; e.g., downloaded from a trusted party using a
secure communication channel, such as [<a href="#ref-TLS" title=""The TLS Protocol Version 1.0"">TLS</a>] or [<a href="#ref-IPSEC" title=""IP Security Document Roadmap"">IPSEC</a>], or secured by
the digital signature of a trusted party [<a href="#ref-XMLDSIG" title=""(Extensible Markup Language) XML-Signature Syntax and Processing"">XMLDSIG</a>].
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
The following persons, in alphabetic order, contributed substantially
to the material herein:
Ian Grigg
Renato Iannella
Yoshiaki Nakajima
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Normative References</span>
[<a id="ref-ISO4217">ISO4217</a>] "Codes for the representation of currencies and
funds", ISO 4217, 1995.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-URN">URN</a>] Moats, R., "URN Syntax", <a href="./rfc2141">RFC 2141</a>, May 1997.
[<a id="ref-URN-NS-IETF">URN-NS-IETF</a>] Moats, R., "A URN Namespace for IETF Documents", <a href="./rfc2648">RFC</a>
<a href="./rfc2648">2648</a>, August 1999.
[<a id="ref-XML">XML</a>] "Extensible Mark Up Language (XML) 1.0 (Second
Edition)", A W3C Recommendation,
<<a href="http://www.w3.org/TR/REC-xml">http://www.w3.org/TR/REC-xml</a>>, October 2000.
[<a id="ref-XML-ns">XML-ns</a>] "Namespaces in XML", A W3C Recommendation,
<<a href="http://www.w3.org/TR/REC-xml-names">http://www.w3.org/TR/REC-xml-names</a>>, January 1999.
[<a id="ref-XML-Registry">XML-Registry</a>] Mealling, M., "The IETF XML Registry", <a href="https://www.rfc-editor.org/bcp/bcp81">BCP 81</a>, <a href="./rfc3688">RFC</a>
<a href="./rfc3688">3688</a>, January 2004.
[<a id="ref-XML-Schema-1">XML-Schema-1</a>] Thompson, H., Beech, D., Maloney, M., and N.
Mendelsohn, "XML Schema Part 1: Structures W3C
Recommendation.", <<a href="http://www.w3.org/TR/xmlschema-1/">http://www.w3.org/TR/xmlschema-1/</a>>,
May 2001.
[<a id="ref-XML-Schema-2">XML-Schema-2</a>] Biron, P. and A. Malhotra, "XML Schema Part 2:
Datatypes W3C Recommendation.",
<<a href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2/</a>>, May 2001.
<span class="grey">Fujimura, et al. Informational [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Informative References</span>
[<a id="ref-VTS">VTS</a>] Fujimura, K. and D. Eastlake, "Requirements and Design
for Voucher Trading System (VTS)", <a href="./rfc3506">RFC 3506</a>, March
2003.
[<a id="ref-IPSEC">IPSEC</a>] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", <a href="./rfc2411">RFC 2411</a>, November 1998.
[<a id="ref-TLS">TLS</a>] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", <a href="./rfc2246">RFC 2246</a>, January 1999.
[<a id="ref-VTS-API">VTS-API</a>] Terada, M. and K. Fujimura, "Voucher Trading System
Application Programming Interface (VTS-API)", <a href="./rfc4154">RFC</a>
<a href="./rfc4154">4154</a>, September 2005.
[<a id="ref-XMLDSIG">XMLDSIG</a>] Eastlake 3rd, D., Reagle, J., and D. Solo,
"(Extensible Markup Language) XML-Signature Syntax and
Processing", <a href="./rfc3275">RFC 3275</a>, March 2002.
Authors' Addresses
Ko Fujimura
NTT Corporation
1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN
Phone: +81-(0)46-859-3053
Fax: +81-(0)46-855-1730
EMail: [email protected]
Masayuki Terada
NTT DoCoMo, Inc.
3-5 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-8536 JAPAN
Phone: +81-(0)46-840-3809
Fax: +81-(0)46-840-3705
EMail: [email protected]
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Phone: 1-508-786-7554 (work)
1-508-634-2066 (home)
EMail: [email protected]
<span class="grey">Fujimura, et al. Informational [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc4153">RFC 4153</a> XML Voucher: Generic Voucher Language September 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
[email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Fujimura, et al. Informational [Page 21]
Annotations
Select text to annotate