One document matched: draft-ietf-trade-voucher-lang-06.txt
Differences from draft-ietf-trade-voucher-lang-05.txt
Trade Working Group February 2004
INTERNET-DRAFT Ko Fujimura
NTT
Masayuki Terada
NTT DoCoMo
Expires: August 2004
XML Voucher: Generic Voucher Language
<draft-ietf-trade-voucher-lang-06.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://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.
Copyright (C) The Internet Society (2004). All Rights Reserved.
K. Fujimura, M. Terada [Page 1]
INTERNET-DRAFT XML Voucher February 2004
Acknowledgements
The following persons, in alphabetic order, contributed substantially
to the material herein:
Donald Eastlake 3rd
Ian Grigg
Renato Iannella
Yoshiaki Nakajima
Table of Contents
Status of this Memo ...............................................1
Abstract ..........................................................1
Acknowledgments ...................................................2
Table of Contents .................................................2
1. Introduction ...................................................3
2. Processing Model ...............................................3
3. Trust Model ....................................................4
4. Component Structure ............................................5
5. Syntax Overview and Examples ...................................7
6. Syntax and Semantics ...........................................8
6.1 <Voucher> ..................................................8
6.2 <Title> ....................................................9
6.3 <Description> ..............................................9
6.4 <Provider> .................................................9
6.5 <Issuer> ...................................................9
6.6 <Holder> ..................................................10
6.7 <Collector> ...............................................10
6.8 <Value> ...................................................11
6.8.1 <Ratio> .................................................12
6.8.2 <Fixed> .................................................12
6.9 <Merchandise> .............................................13
6.10 <ValidPeriod> ............................................14
6.11 <Conditions> .............................................14
7. IANA Considerations ...........................................14
8. VTS Schema Example ............................................17
9. Security Considerations .......................................17
10. Normative References ..........................................17
11. Informational References ......................................18
12. Author's Address ..............................................18
Full Copyright Statement ..........................................19
K. Fujimura, M. Terada [Page 2]
INTERNET-DRAFT XML Voucher February 2004
1. Introduction
This document, XML Voucher, specifies rules for defining voucher
properties in XML syntax. The motivation and background of the
specification are described in [VTS].
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, traded among users, and finally
collected by the collector using VTS.
This document defines the syntax and semantics of Voucher
Component, which defines voucher meaning and processing rules in
XML syntax [XML]. A Voucher Component define the properties that
must be satisfied to allow the voucher to be processed by VTS or
other trading systems, e.g., wallet or merchant system. VTS
definitions and models are also defined in [VTS].
Note: This document uses "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
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 this architecture, instead of specifying a standard
voucher transfer protocol, two specifications, i.e., Voucher
Component and VTS-API specifications, are standardized (Figure 1).
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 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 [VTS-API].
K. Fujimura, M. Terada [Page 3]
INTERNET-DRAFT XML Voucher February 2004
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
3. Trust Model
A voucher is trusted if the Issuer and VTS Provider are trusted,
since 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 Issuer and VTS Provider depends on the
type (or Promise) of the voucher. To provide the information needed
for verification, the conditions of 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.
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.
K. Fujimura, M. Terada [Page 4]
INTERNET-DRAFT XML Voucher February 2004
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 conducting a transaction.
4. Component Structure
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
o Restrictions applied to the voucher
- Participants (VTS Provider, Issuer, Holder, and Collector)
- Objects (merchandise) to be claimed
- Time when valid (validity period)
- Others
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 Title Component, Description
Component, Provider Component, Issuer Component, Holder Component,
Collector Component, Value Component, Merchandise Component,
ValidPeriod Component, and Condition Component as follows:
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
K. Fujimura, M. Terada [Page 5]
INTERNET-DRAFT XML Voucher February 2004
Provides restrictions on the Collector of the voucher.
Value Component
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.
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.
Merchandise Component
Provides 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, 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
K. Fujimura, M. Terada [Page 6]
INTERNET-DRAFT XML Voucher February 2004
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):
<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
1st in 2001 to March 31st in 2002. To claim this offer, one voucher
must be spent.
<?xml version="1.0"?>
<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"/>
K. Fujimura, M. Terada [Page 7]
INTERNET-DRAFT XML Voucher February 2004
<Conditions>
The value of this coupon is subject to tax.
</Conditions>
</Voucher>
6. Syntax and Semantics
The general structure of an XML voucher is described in Component
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:
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
[URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF]
and extended by [XML-Registry].
This namespace is also used for unqualified elements in voucher
examples.
6.1 <Voucher>
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>
K. Fujimura, M. Terada [Page 8]
INTERNET-DRAFT XML Voucher February 2004
6.2 <Title>
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"/>
6.3 <Description>
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"/>
6.4 <Provider>
The <Provider> element may contain any elements 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 [VTS-API]). 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" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="string"/>
</complexType>
6.5 <Issuer>
K. Fujimura, M. Terada [Page 9]
INTERNET-DRAFT XML Voucher February 2004
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 [VTS-API].
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 as
sub-elements using [XML-ns]. An example of such schema definition is
described in Section 8.
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.4.
If the <Issuer> element is omitted, it MUST be interpreted that there
are no restrictions on the Issuer.
6.6 <Holder>
The <Holder> element may contain any elements that is used to specify
or restrict the Holder of the voucher.
The Holder of the voucher is generally managed by the VTS [VTS-API].
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 as
sub-elements using [XML-ns].
The <Holder> element has a string-type "name" attribute that is used
to specify the name of the Holder.
The <Holder> element is defined by the following schema:
<element name="Holder" type="gvl:RoleType"/>
The <RoleType> element type is defined in Section 6.4.
If the <Holder> element is omitted, it MUST be interpreted that there
are no restrictions on the Holder.
6.7 <Collector>
The <Collector> element may contain any elements 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
K. Fujimura, M. Terada [Page 10]
INTERNET-DRAFT XML Voucher February 2004
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
as sub-elements using [XML-ns].
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 Section 6.4.
If the <Collector> element is omitted, it MUST be interpreted that
there are no restrictions on the Collector.
6.8 <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.
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 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.
K. Fujimura, M. Terada [Page 11]
INTERNET-DRAFT XML Voucher February 2004
If the "spend" attribute is omitted 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>
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.8.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.8.2 <Fixed>
K. Fujimura, M. Terada [Page 12]
INTERNET-DRAFT XML Voucher February 2004
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="short" default="0"/>
</complexType>
6.9 <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 are depending 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].
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"/>
K. Fujimura, M. Terada [Page 13]
INTERNET-DRAFT XML Voucher February 2004
</sequence>
</complexType>
6.10 <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.11 <Conditions>
The <Conditions> element contains any other restrictions or
conditions applied. This is intended to cover contracts between the
issuer and 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"/>
7. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [XML-Registry].
Two URI assignments are requested.
Registration request for the vts-lang namespace:
URI: urn:ietf:params:xml:ns:vts-lang
Registrant Contact: See the "Author's Address" section of this
K. Fujimura, M. Terada [Page 14]
INTERNET-DRAFT XML Voucher February 2004
document.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the vts-lang XML schema:
URI: urn:ietf:params:xml:schema:vts-lang
Registrant Contact: See the "Author's Address" section of this
document.
XML:
BEGIN
<?xml version="1.0"?>
<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>
<element name="Value" type="gvl:ValueType"/>
K. Fujimura, M. Terada [Page 15]
INTERNET-DRAFT XML Voucher February 2004
<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"/>
<attribute name="end" type="dateTime"/>
</complexType>
<element name="Conditions" type="string"/>
</schema>
END
K. Fujimura, M. Terada [Page 16]
INTERNET-DRAFT XML Voucher February 2004
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
The VTS must provide a means of preventing forgery, alteration,
duplicate-redemption, reproduction of a voucher, and non-repudiation
of transactions as described in Section 3.2 of [VTS]. These security
requirements, however, mainly follow the VTS plug-ins and their
protocols. This document assumes that the VTS plug-ins are trusted
and installed by some means, e.g., manually checked like other
download applications.
The Voucher Component, however, defines restrictions on VTS Provider
(or VTS plug-in), and if this information is altered, incorrect VTS
plug-ins not accepted by the issuer could be used, and a forged
voucher could be verified as if it were valid. To prevent this
situation, the Voucher Component should be acquired securely, e.g.,
downloaded from a trusted party using a secure communication channel,
such as [TLS], or [IPSEC], or secured by the digital signature of a
trusted party.
10. Normative References
[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.
[URN] R. Moats, "URN Syntax", RFC2141, May 1997.
[URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents",
RFC2648, August 1999.
K. Fujimura, M. Terada [Page 17]
INTERNET-DRAFT XML Voucher February 2004
[XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A
W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000.
[XML-ns] "Namespaces in XML", A W3C Recommendation,
<http://www.w3.org/TR/REC-xml-names>, January 1999.
[XML-Registry] M. Mealling, "The IETF XML Registry", RFC3688
January 2004.
[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.
11. Informational References
[VTS] K. Fujimura, D Eastlake, "Requirements and Design for Voucher
Trading System (VTS)", RFC3506, March 2003.
[IPSEC] R. Thayer, N. Doraswamy, and R. Glenn, "IP Security Document
Roadmap", RFC2411, November 1998
[TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246,
January 1999.
[VTS-API] M. Terada and K. Fujimura, "Voucher Trading System
Application Programming Interface (VTS-API)",
draft-ietf-trade-voucher-vtsapi-06.txt, February 2004.
[XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature
Syntax and Processing", RFC3275, March 2002.
12. Author's Address
Ko Fujimura
NTT Corporation
1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN
Phone: +81-(0)46-859-3814
Fax: +81-(0)46-859-8329
Email: fujimura@isl.ntt.co.jp
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-3364
Email: te@mml.yrp.nttdocomo.co.jp
K. Fujimura, M. Terada [Page 18]
INTERNET-DRAFT XML Voucher February 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
K. Fujimura, M. Terada [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 04:48:39 |