draft-ietf-trade-voucher-lang-07.txt   rfc4153.txt 
INTERNET-DRAFT Ko Fujimura
NTT Network Working Group K. Fujimura
Masayuki Terada Request for Comments: 4153 NTT
Category: Informational M. Terada
NTT DoCoMo NTT DoCoMo
Donald E. Eastlake 3rd D. Eastlake 3rd
Motorola Laboratories Motorola Laboratories
Expires July 2005 January 2005 September 2005
XML Voucher: Generic Voucher Language XML Voucher: Generic Voucher Language
<draft-ietf-trade-voucher-lang-07.txt>
Status of this Memo Status of This Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Distribution of this document is unlimited. Comments should be sent
to the author or the IETF TRADE working group
<ietf-trade@lists.elistx.com>.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This memo provides information for the Internet community. It does
http://www.ietf.org/shadow.html not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies rules for defining voucher properties in XML This document specifies rules for defining voucher properties in XML
syntax. A voucher is a logical entity that represents a right to syntax. A voucher is a logical entity that represents a right 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
wide-range of electronic-values, including coupons, tickets, loyalty range of electronic values, including coupons, tickets, loyalty
points, and gift certificates, which are often necessary to process points, and gift certificates, which often have to be processed in
in the course of payment and/or delivery transactions. the course of payment and/or delivery transactions.
Acknowledgements
The following persons, in alphabetic order, contributed substantially
to the material herein:
Ian Grigg
Renato Iannella
Yoshiaki Nakajima
Table of Contents Table of Contents
1. Introduction ...................................................3 1. Introduction ................................................. 2
2. Processing Model ...............................................3 2. Processing Model ............................................. 2
3. Trust Model ....................................................4 3. Trust Model .................................................. 4
4. Component Structure ............................................5 4. Component Structure .......................................... 4
5. Syntax Overview and Examples ...................................7 5. Syntax Overview and Examples ................................. 6
6. Syntax and Semantics ...........................................8 6. Syntax and Semantics ......................................... 8
6.1 <Voucher> ..................................................8 6.1. <Voucher> ............................................... 8
6.2 <Title> ....................................................9 6.2. <Title> ................................................. 9
6.3 <Description> ..............................................9 6.3. <Description> ........................................... 9
6.4 <Provider> .................................................9 6.4. <Provider> .............................................. 9
6.5 <Issuer> ...................................................9 6.5. <Issuer> ................................................ 10
6.6 <Holder> ..................................................10 6.6. <Holder> ................................................ 10
6.7 <Collector> ...............................................10 6.7. <Collector> ............................................. 11
6.8 <Value> ...................................................11 6.8. <Value> ................................................. 11
6.8.1 <Ratio> .................................................12 6.8.1. <Ratio> .......................................... 13
6.8.2 <Fixed> .................................................12 6.8.2. <Fixed> .......................................... 13
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
Normative References .............................................17 6.9. <Merchandise> ........................................... 14
Informational References .........................................18 6.10. <ValidPeriod> .......................................... 14
Author's Address .................................................19 6.11. <Conditions> ........................................... 15
Copyright and Disclaimer..........................................19 7. IANA Considerations .......................................... 15
File name and Expiration..........................................19 8. VTS Schema Example ........................................... 18
9. Security Considerations ...................................... 18
10. Acknowledgements ............................................. 19
11. Normative References ......................................... 19
12. Informative References ....................................... 20
1. Introduction 1. Introduction
This document, XML Voucher, specifies rules for defining voucher This document specifies rules for defining voucher properties in XML
properties in XML syntax. The motivation and background of the syntax. The motivation and background of the specification are
specification are described in [VTS]. described in [VTS].
A voucher is a logical entity that represents a certain right and A voucher is a logical entity that represents a certain right and
is logically managed by the Voucher Trading System (VTS). A voucher that is logically managed by the Voucher Trading System (VTS). A
is generated by the issuer, traded among users, and finally voucher 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 the syntax and semantics of Voucher This document defines the syntax and semantics of the Voucher
Component, which defines voucher meaning and processing rules in Component, which defines voucher meaning and processing rules in XML
XML syntax [XML]. A Voucher Component define the properties that syntax [XML]. A Voucher Component defines the properties that must
must be satisfied to allow the voucher to be processed by VTS or be satisfied to allow the voucher to be processed by VTS or other
other trading systems, e.g., wallet or merchant system. VTS trading systems; e.g., a wallet or merchant system. VTS definitions
definitions and models are also defined in [VTS]. and models are also defined in [VTS].
Note: This document uses "voucher" as an "instance of voucher" Note: This document uses "voucher" as an "instance of voucher", whose
whose meaning is defined by Voucher Component. In other words, a meaning is defined by the Voucher Component. In other words, a
Voucher Component is NOT a voucher and multiple vouchers can be Voucher Component is NOT a voucher, and multiple vouchers can be
issued and managed by the VTS using the same Voucher Component. issued and managed by the VTS using the 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
this document are to be interpreted as described in [RFC 2119] document are to be interpreted as described in [RFC2119]
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
continually 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 smartcard-based offline VTS is often preferred, whereas
whereas for bonds or securities, the centralized online VTS is for bonds or securities, the centralized online VTS is preferred. It
preferred. It is impractical to define standard protocols for is impractical to define standard protocols for issuing,
issuing, transferring, or redeeming vouchers at this moment. transferring, or redeeming vouchers at this time.
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 VTSes to be added as
plug-ins. In this 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, Voucher Component and
Component and VTS-API specifications, are standardized (Figure 1). VTS-API, are standardized (Figure 1).
After sender and receiver agree on what vouchers are to be traded After the sender and receiver agree on which vouchers are to be
and which VTS is to be used, the issuing system or wallet system traded and which VTS is to be used, the issuing system or wallet
requests the corresponding VTS plug-in to permit the issue, system 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.
API. The VTS then rewrites the ownership of the vouchers using the The VTS then rewrites the ownership of the vouchers using the VTS-
VTS-specific protocol. Finally, a completion event is sent to the specific protocol. Finally, a completion event is sent to the wallet
wallet systems or issuing/collecting systems. systems or issuing/collecting systems.
This document describes the Voucher Component specification. The This document describes the Voucher Component specification. The
VTS-API specification is defined in [VTS-API]. VTS-API specification is defined in [VTS-API].
Sender wallet/Issuing system Receiver wallet/Collecting system Sender wallet/Issuing system Receiver wallet/Collecting system
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
| | | | | | | |
| | Voucher Component | | | | Voucher Component | |
| | (Specifies VTS Provider and Promise) | | | | (Specifies VTS Provider and Promise) | |
| |-------------------------------------------------------->| | | |-------------------------------------------------------->| |
| | | | | | | | | | | |
| | Intention to receive and payment (option) | | | | Intention to receive and payment (option) | |
skipping to change at page 4, line 26 skipping to change at page 3, line 43
| | Issue/transfer/ VTS | | VTS Register | | | | Issue/transfer/ VTS | | VTS Register | |
| | redeem request plug-in | plug-in Listener(*1)| | | | 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 | | |
| | Result |<- - - - - - - ->| Notify(*2) | | | | Result |<- - - - - - - ->| Notify(*2) | |
| |<------------------| | | |------------------>| | | |<------------------| | | |------------------>| |
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
(*1) Registration is optional. Note also that the VTS plug-ins are
(*1) Registration is optional. Note also that the VTS plug-ins are
usually pre-registered when the wallet or collecting system usually pre-registered when the wallet or collecting system
is started. is started.
(*2) If a listener is registered. (*2) If a listener is registered.
Figure 1. Wallet architecture with VTS plug-ins Figure 1. Wallet architecture with VTS plug-ins
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, as
since the Issuer is responsible for the contents of the voucher and the Issuer is responsible for the contents of the voucher and the VTS
the VTS Provider is responsible for preventing ownership from being Provider is responsible for preventing ownership from being assigned
assigned to multiple users. to multiple users.
The trust level required for Issuer and VTS Provider depends on the The trust level required for the Issuer and VTS Provider depends on
type (or Promise) of the voucher. To provide the information needed the type (or Promise) of the voucher. To provide the information
for verification, the conditions of Issuer and VTS Provider are needed for verification, the conditions of the Issuer and VTS
specified in the Voucher Component, and given as input to the Provider are specified in the Voucher Component and given as input to
verifier, e.g., wallet system or other software. The trust of a the verifier; e.g., wallet system or other software. The trust of a
voucher is thus verified through the Voucher Component. This model voucher is thus verified through the Voucher Component. This model
enables trading partners to verify their trust in the voucher enables trading partners to verify their trust in the voucher
regardless of their trust in the partners. regardless of their trust in the partners.
This document assumes that the Voucher Component is the root of This document assumes that the Voucher Component is the root of
trust. If a malicious user could alter the Voucher Component, a trust. If a malicious user could alter the Voucher Component, a
forged voucher, could be verified as valid. forged voucher could be verified as valid.
When a Voucher Component is delivered from the trusted VTS When a Voucher Component is delivered from the trusted VTS Provider,
Provider, Issuer or trusted third party, a secure communication Issuer, or trusted third party, a secure communication channel (e.g.,
channel, e.g., [TLS], [IPSEC], or object security, e.g.,[XMLDSIG] [TLS], [IPSEC], or object security, such as [XMLDSIG]) should be used
should be used to prevent from being altered during the delivery. to prevent alteration during the delivery.
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
sender of the voucher. Note also that a set of trusted Voucher of the voucher. Note also that a set of trusted Voucher Components
Components can be downloaded before conducting a transaction. can be downloaded before a transaction is conducted.
4. Component Structure 4. Component Structure
The Voucher Component provides the information needed to identify The Voucher Component provides the information needed to identify the
the monetary value or merchandize rendered when the voucher is monetary value or merchandize rendered when the voucher is redeemed.
redeemed. It includes: It includes
o How much value/items can be claimed in exchange for the voucher o how much value/items can be claimed in exchange for the voucher,
and
o Restrictions applied to the voucher o restrictions applied to the voucher
- Participants (VTS Provider, Issuer, Holder, and Collector)
- Objects (merchandise) to be claimed - participants (VTS Provider, Issuer, Holder, and Collector),
- Time when valid (validity period)
- Others - objects (merchandise) to be claimed,
- time when valid (validity period), and
- others.
The Voucher Component also provides common properties useful for The Voucher Component also provides common properties useful for
displaying and manipulating the contents of wallet systems. It displaying and manipulating the contents of wallet systems. It
includes the title and description of each voucher. includes the title and description of each voucher.
The Voucher Component contains the Title Component, Description The Voucher Component contains the following components:
Component, Provider Component, Issuer Component, Holder Component,
Collector Component, Value Component, Merchandise Component,
ValidPeriod Component, and Condition Component as follows:
Title Component Title Component
Provides the title of the voucher. This is mainly for listing Provides the title of the voucher. This is mainly for listing the
the entities stored in a wallet system. 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
listing the entities stored in a wallet system. listing the entities stored in a wallet system.
Provider Component Provider Component
Provides restrictions on which VTS Provider (or VTS plug-in) can Provides restrictions on which VTS Provider (or VTS plug-in) can
be used for trading the voucher. be used for trading the voucher.
Issuer Component Issuer Component
Provides restrictions on the Issuer of the voucher. Provides restrictions on the Issuer of the voucher.
Holder Component Holder Component
Provides restrictions on the Holder of the voucher. Provides restrictions on the Holder of the voucher.
Collector Component Collector Component
Provides restrictions on the Collector of the voucher. Provides restrictions on the Collector of the voucher.
Value Component Value Component
Provides the value of each voucher. There are two types of Provides the value of each voucher. There are two types of
values, i.e., fixed and ratio values. For a fixed value, the values: fixed and ratio values. For a fixed value, the currency
currency and the figure is specified. For a ratio value, the and the figure is specified. For a ratio value, the discount
discount ratio of the corresponding merchandize is specified. ratio of the corresponding merchandize is specified.
The Value Component also indicates the number of vouchers to be The Value Component also indicates the number of vouchers to be
redeemed for claiming the merchandise or monetary value specified redeemed for claiming the merchandise or monetary value specified
in Merchandise Component or Value Component. If "n"(>0) is in the Merchandise Component or Value Component. If "n" (>0) is
specified, the merchandize or monetary value can be claimed in specified, the merchandize or monetary value can be claimed in
exchange for "n sheets of" vouchers. If "0" is specified, it exchange for "n sheets of" vouchers. If "0" is specified, it can
can be used repeatedly. be used repeatedly.
Merchandise Component Merchandise Component
Provides restrictions on the object to be claimed. Provides restrictions on the object to be claimed. The domain-
Domain-specific meaning of the voucher, e.g., reference number of specific meaning of the voucher (e.g., reference number of the
the merchandize or seat number for an event ticket, is specified merchandize or seat number for an event ticket) is specified to
to identify the merchandize rendered when the voucher is identify the merchandize rendered when the voucher is redeemed.
redeemed.
ValidPeriod Component ValidPeriod Component
Provides restrictions on the validity period of the voucher, Provides restrictions on the validity period of the voucher; i.e.,
i.e., start date and end date. start date and end date.
Condition Component Condition Component
Provides any other applicable restrictions. This is intended to Provides any other applicable restrictions. This is intended to
cover contracts between the issuer and holder of the cover contracts between the issuer and holder of the voucher in
voucher in natural language form. natural language form.
Using the above Components, semantics for diverse types of vouchers Using the above Components, semantics for diverse types of vouchers
can be defined as shown in Table 1. can be defined as shown in Table 1.
+----------------+--------------------------------+---------------+ +----------------+--------------------------------+---------------+
| | Value | Restrictions | | | Value | Restrictions |
| +-----+---------------+----------+---------------+ | +-----+---------------+----------+---------------+
| Examples |Ratio| Fixed |Number | Merchandise | | Examples |Ratio| Fixed |Number | Merchandise |
| | +------+--------+Needed for| | | | +------+--------+needed for| |
| | |Amount|Currency|redemption| | | | |Amount|Currency|redemption| |
+----------------+-----+------+--------+----------+---------------+ +----------------+-----+------+--------+----------+---------------+
|Gift certificate| | 25 | USD | 1 |(Not specified)| |Gift certificate| | 25 | USD | 1 |(Not specified)|
|Loyalty point | | 1 | AUD | 10 |(Not specified)| |Loyalty point | | 1 | AUD | 10 |(Not specified)|
|Member card | 20%| | | 0 |(Not specified)| |Member card | 20%| | | 0 |(Not specified)|
|Coupon | 30%| | | 1 |Beef 500g | |Coupon | 30%| | | 1 |Beef 500g |
|Event ticket | 100%| | | 1 |Hall A, S ,K23 | |Event ticket | 100%| | | 1 |Hall A, S ,K23 |
|Exchange ticket | 100%| | | 1 |ISBN:0071355014| |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 Components.
Component. The formal syntax and semantics are found in Sections 6 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): occurrence):
<Voucher> <Voucher>
(Title) (Title)
(Description)? (Description)?
(Provider) (Provider)
(Issuer)? (Issuer)?
(Holder)? (Holder)?
(Collector)? (Collector)?
(Value) (Value)
(Merchandise)? (Merchandise)?
(ValidPeriod)? (ValidPeriod)?
(Conditions)? (Conditions)?
</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
a book with ISBN number 0071355014. The coupon is valid from April book with ISBN number 0071355014. The coupon is valid from April 1,
1st in 2001 to March 31st in 2002. To claim this offer, one voucher 2001, to March 31, 2002. To claim this offer, one voucher must be
must be spent. spent.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<Voucher xmlns="urn:ietf:params:xml:ns:vts-lang" <Voucher xmlns="urn:ietf:params:xml:ns:vts-lang"
xmlns:vts="http://www.example.com/vts"> xmlns:vts="http://www.example.com/vts">
<Title>IOTP Book Coupon</Title> <Title>IOTP Book Coupon</Title>
<Description>$5 off IOTP Book</Description> <Description>$5 off IOTP Book</Description>
<Provider name="Voucher Exchanger 2002"> <Provider name="Voucher Exchanger 2002">
<vts:Version>VE2.31</vts:Version> <vts:Version>VE2.31</vts:Version>
</Provider> </Provider>
<Issuer name="Alice Book Center, Ltd."> <Issuer name="Alice Book Center, Ltd.">
<vts:KeyInfo> <vts:KeyInfo>
1DA8DFCF95521014BBB7171B95545E8D61AE803F 1DA8DFCF95521014BBB7171B95545E8D61AE803F
</vts:KeyInfo> </vts:KeyInfo>
</Issuer> </Issuer>
<Collector name="Alice Book Center, Ltd."/> <Collector name="Alice Book Center, Ltd."/>
<Value type="discount" spend="1"> <Value type="discount" spend="1">
<Fixed amount="5" currency="USD"/> <Fixed amount="5" currency="USD"/>
</Value> </Value>
<Merchandise> <Merchandise>
<bk:Book xmlns:bk="http://www.example.com/bk" <bk:Book xmlns:bk="http://www.example.com/bk"
bk:isbn="0071355014"/> bk:isbn="0071355014"/>
</Merchandise> </Merchandise>
<ValidPeriod start="2002-04-01" end="2003-03-31"/> <ValidPeriod start="2002-04-01" end="2003-03-31"/>
<Conditions> <Conditions>
The value of this coupon is subject to tax. The value of this coupon is subject to tax.
</Conditions> </Conditions>
</Voucher> </Voucher>
6. Syntax and Semantics 6. Syntax and Semantics
The general structure of an XML Voucher Component is described in The general structure of an XML Voucher Component is described in
Section 4 above. This section details the Voucher Component Section 4. This section details the Voucher Component features.
features. Features described in this section MUST be implemented Features described in this section MUST be implemented unless
unless otherwise indicated. The syntax is defined via otherwise indicated. The syntax is defined via [XML-Schema-1]
[XML-Schema-1] [XML-Schema-2]. For clarity, unqualified elements in [XML-Schema-2]. For clarity, unqualified elements in schema
schema definitions are in the XML schema namespace: definitions are in the XML schema namespace:
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
References to XML Voucher schema defined herein use the prefix References to XML Voucher schema defined herein use the prefix "gvl"
"gvl" and are in the namespace: and are in the namespace:
xmlns:gvl="urn:ietf:params:xml:ns:vts-lang" xmlns:gvl="urn:ietf:params:xml:ns:vts-lang"
This namespace URI for elements defined by this document is a URN This namespace URI for elements defined by this document is a URN
[URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] [URN] that uses the namespace identifier 'ietf', defined by
and extended by [XML-Registry]. [URN-NS-IETF] and extended by [XML-Registry].
This namespace is also used for unqualified elements in voucher This namespace is also used for unqualified elements in voucher
examples. examples.
6.1 <Voucher> 6.1. <Voucher>
The <Voucher> element contains <Title>, <Provider>, and <Value> The <Voucher> element contains <Title>, <Provider>, and <Value>
elements and optionally contains <Description>, <Issuer>, <Holder>, elements and optionally contains <Description>, <Issuer>, <Holder>,
<Collector>, <ValidPeriod>, and <Condition> elements. These <Collector>, <ValidPeriod>, and <Condition> elements. These sub-
sub-elements are defined in the following sections. elements are defined in the following sections.
The <Voucher> element is defined by the following schema: The <Voucher> element is defined by the following schema:
<element name="Voucher" type="gvl:VoucherType"/> <element name="Voucher" type="gvl:VoucherType"/>
<complexType name="VoucherType"> <complexType name="VoucherType">
<sequence> <sequence>
<element ref="gvl:Title"/> <element ref="gvl:Title"/>
<element ref="gvl:Description" minOccurs="0"/> <element ref="gvl:Description" minOccurs="0"/>
<element ref="gvl:Provider"/> <element ref="gvl:Provider"/>
<element ref="gvl:Issuer" minOccurs="0"/> <element ref="gvl:Issuer" minOccurs="0"/>
<element ref="gvl:Holder" minOccurs="0"/> <element ref="gvl:Holder" minOccurs="0"/>
<element ref="gvl:Collector" minOccurs="0"/> <element ref="gvl:Collector" minOccurs="0"/>
<element ref="gvl:Value"/> <element ref="gvl:Value"/>
<element ref="gvl:Merchandise" minOccurs="0"/> <element ref="gvl:Merchandise" minOccurs="0"/>
<element ref="gvl:ValidPeriod" minOccurs="0"/> <element ref="gvl:ValidPeriod" minOccurs="0"/>
<element ref="gvl:Conditions" minOccurs="0"/> <element ref="gvl:Conditions" minOccurs="0"/>
</sequence> </sequence>
</complexType> </complexType>
6.2 <Title> 6.2. <Title>
The <Title> element contains a simpletext title of the voucher. The <Title> element contains a simpletext title of the voucher. This
This is mainly for listing the entities stored in a wallet system. is mainly for listing the entities stored in a wallet system.
The <Title> element has no attribute. The <Title> element has no attribute.
The <Title> element is defined by the following schema: The <Title> element is defined by the following schema:
<element name="Title" type="string"/> <element name="Title" type="string"/>
6.3 <Description> 6.3. <Description>
The <Description> element contains a simpletext description of the The <Description> element contains a simpletext description of the
voucher. This is mainly for listing the entities stored in a voucher. This is mainly for listing the entities stored in a wallet
wallet system. system.
The <Description> element has no attribute. The <Description> element has no attribute.
The <Description> element is defined by the following schema: The <Description> element is defined by the following schema:
<element name="Description" type="string"/> <element name="Description" type="string"/>
6.4 <Provider> 6.4. <Provider>
The <Provider> element may contain any elements that is used to The <Provider> element may contain any element that is used to
specify or restrict the VTS Provider of the voucher. The specify or restrict the VTS Provider of the voucher. The sub-
sub-elements contained in this element depend on the implementation elements contained in this element depend on the implementation of
of the VTS. the VTS.
An implementation of a wallet system may use this information to An implementation of a wallet system may use this information to
identify and/or authenticate the VTS Provider when the VTS plug-in is identify and/or authenticate the VTS Provider when the VTS plug-in is
registered (See Section 7 of [VTS-API]). These registered (see Section 7 of [VTS-API]). These implementation-
implementation-specific elements of the VTS can be extended using specific elements of the VTS can be extended using [XML-ns]. An
[XML-ns]. An example of such schema definition is described in example of such a schema definition is described in Section 8.
Section 8.
The <Provider> element has a string-type "name" attribute that is The <Provider> element has a string-type "name" attribute that is
used to specify the name of the VTS Provider. used to specify the name of the VTS Provider.
The <Provider> element is defined by the following schema: The <Provider> element is defined by the following schema:
<element name="Provider" type="gvl:RoleType"/> <element name="Provider" type="gvl:RoleType"/>
<complexType name="RoleType" mixed="true"> <complexType name="RoleType" mixed="true">
<sequence> <sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
<attribute name="name" type="string"/> <attribute name="name" type="string"/>
</complexType> </complexType>
6.5. <Issuer>
6.5 <Issuer>
The <Issuer> element may contain any element that is used to specify The <Issuer> element may contain any element that is used to specify
or restrict the Issuer of the voucher. or restrict the Issuer of the voucher.
The Issuer of the voucher is generally managed by the VTS [VTS-API]. 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 There is no need to specify the Issuer of the voucher using this
element if there are no restrictions on the Issuer. element if there are no restrictions on the Issuer.
An implementation of a VTS may use this element to describe the An implementation of a VTS may use this element to describe the
authentication data and/or qualification information of the authentication data and/or qualification information of the Issuer.
Issuer. This implementation-specific information can be extended as This implementation-specific information can be extended through
sub-elements using [XML-ns]. An example of such schema definition is sub-elements using [XML-ns]. An example of such a schema definition
described in Section 8. is described in Section 8.
The <Issuer> element has a string-type "name" attribute that is used The <Issuer> element has a string-type "name" attribute that is used
to specify the name of the Issuer. to specify the name of the Issuer.
The <Issuer> element is defined by the following schema: The <Issuer> element is defined by the following schema:
<element name="Issuer" type="gvl:RoleType"/> <element name="Issuer" type="gvl:RoleType"/>
The <RoleType> element type is defined in Section 6.4. The <RoleType> element type is defined in Section 6.4.
If the <Issuer> element is omitted, it MUST be interpreted that there If the <Issuer> element is omitted, it MUST be interpreted that there
are no restrictions on the Issuer. are no restrictions on the Issuer.
6.6 <Holder> 6.6. <Holder>
The <Holder> element may contain any elements that is used to specify The <Holder> element may contain any element that is used to specify
or restrict the Holder of the voucher. or restrict the Holder of the voucher.
The Holder of the voucher is generally managed by the VTS [VTS-API]. 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 There is no need to specify the Holder of the voucher using this
element if there are no restrictions on the Holder. element if there are no restrictions on the Holder.
An implementation of a VTS may use this element to describe the An implementation of a VTS may use this element to describe the
authentication data and/or qualification information of the authentication data and/or qualification information of the Holder.
Holder. This implementation-specific information can be extended as This implementation-specific information can be extended through
sub-elements using [XML-ns]. sub-elements using [XML-ns].
The <Holder> element has a string-type "name" attribute that is used The <Holder> element has a string-type "name" attribute that is used
to specify the name of the Holder. to specify the name of the Holder.
The <Holder> element is defined by the following schema: The <Holder> element is defined by the following schema:
<element name="Holder" type="gvl:RoleType"/> <element name="Holder" type="gvl:RoleType"/>
The <RoleType> element type is defined in Section 6.4. The <RoleType> element type is defined in Section 6.4.
If the <Holder> element is omitted, it MUST be interpreted that there If the <Holder> element is omitted, it MUST be interpreted that there
are no restrictions on the Holder. are no restrictions on the Holder.
6.7 <Collector> 6.7. <Collector>
The <Collector> element may contain any elements that is used to The <Collector> element may contain any element that is used to
specify or restrict the Collector of the voucher. specify or restrict the Collector of the voucher.
There is no need to specify the Collector of the voucher using this There is no need to specify the Collector of the voucher using this
element if there are no restrictions on the Collector. element if there are no restrictions on the Collector.
An implementation of a VTS may use this element to describe the An implementation of a VTS may use this element to describe the
authentication data and/or qualification information of the authentication data and/or qualification information of the
Collector. This implementation-specific information can be extended Collector. This implementation-specific information can be extended
as sub-elements using [XML-ns]. through sub-elements using [XML-ns].
The <Collector> element has a string-type "name" attribute that is The <Collector> element has a string-type "name" attribute that is
used to specify the name of the Collector. used to specify the name of the Collector.
The <Collector> element is defined by the following schema: The <Collector> element is defined by the following schema:
<element name="Collector" type="gvl:RoleType"/> <element name="Collector" type="gvl:RoleType"/>
The <RoleType> element type is defined in Section 6.4. The <RoleType> element type is defined in Section 6.4.
If the <Collector> element is omitted, it MUST be interpreted that If the <Collector> element is omitted, it MUST be interpreted that
there are no restrictions on the Collector. there are no restrictions on the Collector.
6.8 <Value> 6.8. <Value>
The <Value> element optionally contains a <Fixed> or a <Ratio> The <Value> element optionally contains a <Fixed> or <Ratio> element
element but not both. These sub-elements are defined in the but not both. These sub-elements are defined in the following
following sections. sections.
The <Value> element has a "type" attribute that is used to specify The <Value> element has a "type" attribute that is used to specify
the value process type. This attribute is provided to calculate the the value process type. This attribute is provided to calculate the
amount paid when the vouchers are redeemed at Merchant site, etc. amount paid when the vouchers are redeemed at Merchant site, etc.
The following identifiers are defined for the "type" attribute. The following identifiers are defined for the "type" attribute.
Exchange: Items specified in the <Merchandise> element can be Exchange: Items specified in the <Merchandise> element can be claimed
claimed in exchange for the voucher. If this type is selected, in exchange for the voucher. If this type is selected, neither
neither <Ratio> nor <Fixed> element MUST be specified. Note that the <Ratio> nor the <Fixed> element MUST be specified. Note that
this value process type has the same meaning as: this value process type has the same meaning as:
<Value type="discount"><Ratio percentage="100"/></Value>
<Value type="discount"><Ratio percentage="100"/></Value>
Discount: Items specified in the <Merchandise> element can be Discount: Items specified in the <Merchandise> element can be
purchased at the discount price calculated by the <Ratio> or purchased at the discount price calculated by the <Ratio> or
<Fixed> element. <Fixed> element.
Monetary: Items specified in the <Merchandise> element can be Monetary: Items specified in the <Merchandise> element can be
purchased using the value of the voucher. (Note: if the purchased using the value of the voucher. (Note: if the
<Merchandise> element is not specified, the voucher can be used <Merchandise> element is not specified, the voucher can be used
for any purchase.) If this type is selected, the <Fixed> element for any purchase.) If this type is selected, the <Fixed> element
MUST be specified. MUST be specified.
The <Value> element also has a "spend" attribute that is used to The <Value> element also has a "spend" attribute that is used to
specify the number of vouchers to be redeemed for claiming the specify the number of vouchers to be redeemed for claiming the goods,
goods, services, or monetary value specified. For example, if "n" services, or monetary value specified. For example, if "n" (>0) is
(>0) is specified, goods etc. can be claimed in exchange for "n specified, goods can be claimed in exchange for "n sheets of"
sheets of" vouchers. (Note: Multiple vouchers for the same Voucher vouchers. (Note: Multiple vouchers for the same Voucher Component
Component must exist in this case.) If "0" is specified, it can be must exist in this case.) If "0" is specified, it can be used
used repeatedly. repeatedly.
If the "spend" attribute is omitted or the whole element is omitted, If the "spend" attribute or the whole element is omitted, it MUST be
it MUST be interpreted that "1" is specified for the "spend" interpreted that "1" is specified for the "spend" attribute.
attribute.
The <Value> element is defined by the following schema: The <Value> element is defined by the following schema:
<element name="Value" type="gvl:ValueType"/> <element name="Value" type="gvl:ValueType"/>
<complexType name="ValueType"> <complexType name="ValueType">
<sequence minOccurs="0"> <sequence minOccurs="0">
<choice> <choice>
<element name="Ratio" type="gvl:RatioValueType"/> <element name="Ratio" type="gvl:RatioValueType"/>
<element name="Fixed" type="gvl:FixedValueType"/> <element name="Fixed" type="gvl:FixedValueType"/>
</choice> </choice>
</sequence> </sequence>
<attribute name="type" type="gvl:ValueProcessType" <attribute name="type" type="gvl:ValueProcessType"
use="required"/> use="required"/>
<attribute name="spend" type="nonNegativeInteger" <attribute name="spend" type="nonNegativeInteger"
default="1"/> default="1"/>
</complexType> </complexType>
The <ValueProcessType> element type is defined by the following The <ValueProcessType> element type is defined by the following
schema: schema:
<simpleType name="ValueProcessType"> <simpleType name="ValueProcessType">
<restriction base="string"> <restriction base="string">
<enumeration value="exchange"/> <enumeration value="exchange"/>
<enumeration value="discount"/> <enumeration value="discount"/>
<enumeration value="monetary"/> <enumeration value="monetary"/>
</restriction> </restriction>
</simpleType> </simpleType>
6.8.1 <Ratio> 6.8.1. <Ratio>
The <Ratio> element does not contain any contents. The <Ratio> element does not contain any contents.
The <Ratio> element has a "percentage" attribute that is used to The <Ratio> element has a "percentage" attribute that is used to
specify the discount ratio of the price of the corresponding specify the discount ratio of the price of the corresponding
merchandize in percentage. merchandize in percentage.
The <RatioValueType> element type is defined by the schema: The <RatioValueType> element type is defined by the following schema:
<complexType name="RatioValueType"> <complexType name="RatioValueType">
<attribute name="percentage" use="required"> <attribute name="percentage" use="required">
<simpleType> <simpleType>
<restriction base="float"> <restriction base="float">
<maxInclusive value="100"/> <maxInclusive value="100"/>
</restriction> </restriction>
</simpleType> </simpleType>
</attribute> </attribute>
</complexType> </complexType>
6.8.2. <Fixed>
6.8.2 <Fixed>
The <Fixed> element does not contain any contents. The <Fixed> element does not contain any contents.
The <Fixed> element has "currency" and "amount" attributes The <Fixed> element has "currency" and "amount" attributes and
and optionally a "decimalPower" attribute as follows: optionally a "decimalPower" attribute as follows:
Currency: Provides the unit of the monetary value in the three Currency: Provides the unit of the monetary value in the three letter
letter ISO currency code [ISO4217]. For example, for US dollars ISO currency code [ISO4217]. For example, US dollars is "USD".
it is "USD".
Amount: Provides the amount of the monetary value per voucher. Amount: Provides the amount of the monetary value per voucher.
DecimalPower: Provides the number of decimal digits from the DecimalPower: Provides the number of decimal digits from the decimal
decimal point applied to the base for the "amount" attribute point applied to the base for the "amount" attribute above. If
above. If the "decimalPower" attribute is omitted, it MUST be the "decimalPower" attribute is omitted, it MUST be interpreted
interpreted that "0" is specified for the "decimalPower" that "0" is specified for the "decimalPower" attribute.
attribute.
For example, with a dollar currency denominated in cents, "1" is For example, with a dollar currency denominated in cents, "1" is
specifed for the "amount" attribute, and "-2" is specified for the specified for the "amount" attribute, and "-2" is specified for the
"decimalPower" attribute. Alternately, "0.01" is specified for "decimalPower" attribute. Alternately, "0.01" is specified for the
the "amount" attribute and the "decimalPower" attribute is omitted. "amount" attribute, and the "decimalPower" attribute is omitted.
The <FixedValueType> type is defined by the following definition: The <FixedValueType> type is defined follows:
<complexType name="FixedValueType"> <complexType name="FixedValueType">
<attribute name="currency" type="string" use="required"/> <attribute name="currency" type="string" use="required"/>
<attribute name="amount" type="float" use="required"/> <attribute name="amount" type="float" use="required"/>
<attribute name="decimalPower" type="short" default="0"/> <attribute name="decimalPower" type="short" default="0"/>
</complexType> </complexType>
6.9 <Merchandise> 6.9. <Merchandise>
The <Merchandise> element may contain any elements used to specify or The <Merchandise> element may contain any element used to specify or
restrict the goods or services rendered when the voucher is redeemed. restrict the goods or services rendered when the voucher is redeemed.
The sub-elements contained in this element are depending on the The sub-elements contained in this element depend on the application
application of the voucher and are left to the other domain-specific of the voucher and are left to the other domain-specific
specifications. Domain-specific elements can be extended as specifications. Domain-specific elements can be extended as sub-
sub-elements using [XML-ns]. elements using [XML-ns].
This element is intended to be interpreted by a collecting system. This element is intended to be interpreted by a collecting system.
An implementation of a wallet system does not have to use this An implementation of a wallet system does not have to use this
element. Any restrictions applied should also be described in the element. Any restrictions applied should also be described in the
<Description> element or the <Conditions> elements in natural <Description> element or the <Conditions> elements in natural
language form to enable users to check the restrictions. language form to enable users to check the restrictions.
The <Merchandise> element does not have any attribute. The <Merchandise> element does not have any attribute.
The <Merchandise> element is defined by the following schema: The <Merchandise> element is defined by the following schema:
<element name="Merchandise" type="gvl:MerchandiseType"/> <element name="Merchandise" type="gvl:MerchandiseType"/>
<complexType name="MerchandiseType" mixed="true"> <complexType name="MerchandiseType" mixed="true">
<sequence> <sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</sequence> </complexType>
</complexType>
6.10 <ValidPeriod> 6.10. <ValidPeriod>
The <VaridPeriod> element does not contain any contents. The <ValidPeriod> element does not contain any contents.
The <ValidPeriod> element has dateTime-type "start" and "end" The <ValidPeriod> element has dateTime-type "start" and "end"
attributes that are used to place limits on the validity of the attributes that are used to place limits on the validity of the
voucher. voucher.
The <ValidPeriod> element is defined by the following schema: The <ValidPeriod> element is defined by the following schema:
<element name="ValidPeriod" type="gvl:ValidPeriodType"/> <element name="ValidPeriod" type="gvl:ValidPeriodType"/>
<complexType name="ValidPeriodType"> <complexType name="ValidPeriodType">
<attribute name="start" type="dateTime"/> <attribute name="start" type="dateTime"/>
<attribute name="end" type="dateTime"/> <attribute name="end" type="dateTime"/>
</complexType> </complexType>
If the "start" attribute is omitted, it MUST be interpreted that If the "start" attribute is omitted, it MUST be interpreted that the
the voucher is valid on any date up to the date (inclusive) voucher is valid on any date up to that specified by the end
specified by the end attribute. If the "end" attribute is omitted, attribute (inclusive). If the "end" attribute is omitted, it MUST be
it MUST be interpreted that the voucher is valid from the start interpreted that the voucher is valid from the start attribute with
attribute with no expiry. If neither attribute is specified or the no expiry. If neither attribute is specified or the whole element is
whole element is omitted, it MUST be interpreted that the voucher omitted, it MUST be interpreted that the voucher is valid at any
is valid at any time. time.
6.11 <Conditions> 6.11. <Conditions>
The <Conditions> element contains any other restrictions or The <Conditions> element contains any other restrictions or
conditions applied. This is intended to cover contracts between the conditions applied. This is intended to cover contracts between the
issuer and holder of the voucher in natural language form. issuer and the holder of the voucher in natural language form.
An implementation of a wallet system SHOULD provide a means of An implementation of a wallet system SHOULD provide a means of
displaying the text in this element. displaying the text in this element.
The <Conditions> element has no attribute. The <Conditions> element has no attribute.
The <Conditions> element is defined by the following schema: The <Conditions> element is defined by the following schema:
<element name="Conditions" type="string"/> <element name="Conditions" type="string"/>
7. IANA Considerations 7. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [XML-Registry]. conforming to a registry mechanism described in [XML-Registry]. IANA
Two URI assignments are requested. has registered two URI assignments.
Registration request for the vts-lang namespace: Registration request for the vts-lang namespace:
URI: urn:ietf:params:xml:ns:vts-lang URI: urn:ietf:params:xml:ns:vts-lang
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Authors' Addresses" section of this
document. document.
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
Registration request for the vts-lang XML schema: Registration request for the vts-lang XML schema:
URI: urn:ietf:params:xml:schema:vts-lang URI: urn:ietf:params:xml:schema:vts-lang
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Authors' Addresses" section of this
document. document.
XML: XML:
BEGIN BEGIN
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<schema <schema
targetNamespace="urn:ietf:params:xml:ns:vts-lang" targetNamespace="urn:ietf:params:xml:ns:vts-lang"
xmlns:gvl="urn:ietf:params:xml:ns:vts-lang" xmlns:gvl="urn:ietf:params:xml:ns:vts-lang"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
skipping to change at page 17, line 5 skipping to change at page 18, line 11
<element name="ValidPeriod" type="gvl:ValidPeriodType"/> <element name="ValidPeriod" type="gvl:ValidPeriodType"/>
<complexType name="ValidPeriodType"> <complexType name="ValidPeriodType">
<attribute name="start" type="dateTime"/> <attribute name="start" type="dateTime"/>
<attribute name="end" type="dateTime"/> <attribute name="end" type="dateTime"/>
</complexType> </complexType>
<element name="Conditions" type="string"/> <element name="Conditions" type="string"/>
</schema> </schema>
END END
8. VTS Schema Example 8. VTS Schema Example
An example of the schema definition for a VTS implementation is An example of the schema definition for a VTS implementation is
described below: described below.
<?xml version="1.0"?> <?xml version="1.0"?>
<schema <schema
targetNamespace="http://www.example.com/vts" targetNamespace="http://www.example.com/vts"
xmlns:vts="http://www.example.com/vts" xmlns:vts="http://www.example.com/vts"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<element name="Version" type="string"/> <element name="Version" type="string"/>
<element name="KeyInfo" type="hexBinary"/> <element name="KeyInfo" type="hexBinary"/>
</schema> </schema>
Using this schema definition, the <vts:Version> can be used for Using this schema definition, the <vts:Version> can be used for
specifying the VTS version number and the <vts:KeyInfo> element can specifying the VTS version number, and the <vts:KeyInfo> element can
be used for specifying the Issuer in the Voucher Component as shown be used for specifying the Issuer in the Voucher Component, as shown
in Section 5. in Section 5.
9. Security Considerations 9. Security Considerations
The VTS must provide a means of preventing forgery, alteration, The VTS must provide a means to prevent forgery, alteration,
duplicate-redemption, reproduction of a voucher, and non-repudiation duplicate-redemption, reproduction of a voucher, and non-repudiation
of transactions as described in Section 3.2 of [VTS]. This will of transactions, as described in Section 3.2 of [VTS]. This will
commonly require the presence of a unique serial number or the like commonly require the presence of a unique serial number or the like
in each Voucher instance, usually outside the Voucher Component. in each Voucher instance, usually outside the Voucher Component.
These security requirements, however, mainly follow the VTS plug-ins These security requirements, however, mainly follow the VTS plug-ins
and their protocols. This document assumes that the VTS plug-ins are and their protocols. This document assumes that the VTS plug-ins are
trusted and installed by some means, e.g., manually checked like trusted and are installed by some means; e.g., manually checked as
other download applications. are other download applications.
The Voucher Component, however, defines restrictions on VTS Provider The Voucher Component, however, defines restrictions on the VTS
(or VTS plug-in), and, if this information is altered, incorrect VTS Provider (or VTS plug-in), and, if this information is altered,
plug-ins not accepted by the issuer could be used, allowing a forged incorrect VTS plug-ins not accepted by the issuer could be used,
voucher to be verified as if it were valid. To prevent this allowing a forged voucher to be verified as if it were valid. To
situation, the Voucher Component should be stored and acquired prevent this situation, the Voucher Component should be stored and
securely, e.g., downloaded from a trusted party using a secure acquired securely; e.g., downloaded from a trusted party using a
communication channel, such as [TLS], or [IPSEC], or secured by the secure communication channel, such as [TLS] or [IPSEC], or secured by
digital signature of a trusted party [XMLDSIG]. the digital signature of a trusted party [XMLDSIG].
Normative References 10. Acknowledgements
[ISO4217] "Codes for the representation of currencies and funds", The following persons, in alphabetic order, contributed substantially
ISO 4217, 1995. to the material herein:
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Ian Grigg
Requirement Levels", BCP 14, RFC 2119, March 1997. Renato Iannella
Yoshiaki Nakajima
[URN] R. Moats, "URN Syntax", RFC2141, May 1997. 11. Normative References
[URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents", [ISO4217] "Codes for the representation of currencies and
RFC2648, August 1999. funds", ISO 4217, 1995.
[XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000. Requirement Levels", BCP 14, RFC 2119, March 1997.
[XML-ns] "Namespaces in XML", A W3C Recommendation, [URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
<http://www.w3.org/TR/REC-xml-names>, January 1999.
[XML-Registry] M. Mealling, "The IETF XML Registry", RFC3688 [URN-NS-IETF] Moats, R., "A URN Namespace for IETF Documents", RFC
January 2004. 2648, August 1999.
[XML-Schema-1] H. Thompson, D. Beech, M. Maloney, and [XML] "Extensible Mark Up Language (XML) 1.0 (Second
N. Mendelsohn, "XML Schema Part 1: Structures W3C Recommendation.", Edition)", A W3C Recommendation,
<http://www.w3.org/TR/xmlschema-1/>, May 2001. <http://www.w3.org/TR/REC-xml>, October 2000.
[XML-Schema-2] P. Biron and A Malhotra, "XML Schema Part 2: [XML-ns] "Namespaces in XML", A W3C Recommendation,
Datatypes W3C Recommendation.", <http://www.w3.org/TR/REC-xml-names>, January 1999.
<http://www.w3.org/TR/xmlschema-2/>, May 2001.
Informational References [XML-Registry] Mealling, M., "The IETF XML Registry", BCP 81, RFC
3688, January 2004.
[VTS] K. Fujimura, D Eastlake, "Requirements and Design for Voucher [XML-Schema-1] Thompson, H., Beech, D., Maloney, M., and N.
Trading System (VTS)", RFC3506, March 2003. Mendelsohn, "XML Schema Part 1: Structures W3C
Recommendation.", <http://www.w3.org/TR/xmlschema-1/>,
May 2001.
[IPSEC] R. Thayer, N. Doraswamy, and R. Glenn, "IP Security Document [XML-Schema-2] Biron, P. and A. Malhotra, "XML Schema Part 2:
Roadmap", RFC2411, November 1998 Datatypes W3C Recommendation.",
<http://www.w3.org/TR/xmlschema-2/>, May 2001.
[TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, 12. Informative References
January 1999.
[VTS-API] M. Terada and K. Fujimura, "Voucher Trading System [VTS] Fujimura, K. and D. Eastlake, "Requirements and Design
Application Programming Interface (VTS-API)", for Voucher Trading System (VTS)", RFC 3506, March
draft-ietf-trade-voucher-vtsapi-07.txt, January 2005. 2003.
[XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature [IPSEC] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Syntax and Processing", RFC3275, March 2002. Document Roadmap", RFC 2411, November 1998.
Author's Address [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[VTS-API] Terada, M. and K. Fujimura, "Voucher Trading System
Application Programming Interface (VTS-API)", RFC
4154, September 2005.
[XMLDSIG] Eastlake 3rd, D., Reagle, J., and D. Solo,
"(Extensible Markup Language) XML-Signature Syntax and
Processing", RFC 3275, March 2002.
Authors' Addresses
Ko Fujimura Ko Fujimura
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)46-859-3053 Phone: +81-(0)46-859-3053
Fax: +81-(0)46-855-1730 Fax: +81-(0)46-855-1730
Email: fujimura.ko@lab.ntt.co.jp EMail: fujimura.ko@lab.ntt.co.jp
Masayuki Terada Masayuki Terada
NTT DoCoMo, Inc. NTT DoCoMo, Inc.
3-5 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-8536 JAPAN 3-5 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-8536 JAPAN
Phone: +81-(0)46-840-3809 Phone: +81-(0)46-840-3809
Fax: +81-(0)46-840-3705 Fax: +81-(0)46-840-3705
Email: te@rex.yrp.nttdocomo.co.jp EMail: te@rex.yrp.nttdocomo.co.jp
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Laboratories Motorola Laboratories
155 Beaver Street 155 Beaver Street
Milford, MA 01757 USA Milford, MA 01757 USA
Phone: 1-508-786-7554 (work)
1-508-634-2066 (home)
EMail: Donald.Eastlake@motorola.com
Copyright and Disclaimer Phone: 1-508-786-7554 (work)
1-508-634-2066 (home)
EMail: Donald.Eastlake@motorola.com
Copyright (C) The Internet Society 2005. This document is subject to Full Copyright Statement
the rights, licenses and restrictions contained in BCP 78 and except
as set forth therein, the authors retain all their rights. Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
File name and Expiration Intellectual Property
This file is draft-ietf-trade-voucher-lang-07.txt. 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 BCP 78 and BCP 79.
It expires July 2005. 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
http://www.ietf.org/ipr.
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-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 160 change blocks. 
475 lines changed or deleted 475 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/