draft-ietf-trade-voucher-lang-01.txt   draft-ietf-trade-voucher-lang-02.txt 
Trade Working Group May 2001
Trade Working Group November 2001
INTERNET-DRAFT Ko Fujimura INTERNET-DRAFT Ko Fujimura
Masayuki Terada Masayuki Terada
Expires: November 2001 NTT Expires: May 2002 NTT
XML Voucher: Generic Voucher Language XML Voucher: Generic Voucher Language
<draft-ietf-trade-voucher-lang-01.txt> <draft-ietf-trade-voucher-lang-02.txt>
Status of This Document Status of This Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
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-range of electronic-values, including coupons, tickets, loyalty wide-range of electronic-values, including coupons, tickets, loyalty
points, and gift certificates, which are often necessary to process points, and gift certificates, which are often necessary to process
in the course of payment and/or delivery transactions. in the course of payment and/or delivery transactions.
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 Table of Contents
Status of this Memo ...............................................1 Status of this Memo ...............................................1
Abstract ..........................................................1 Abstract ..........................................................1
1. Introduction ...................................................2 Acknowledgments ...................................................2
Table of Contents .................................................2
1. Introduction ...................................................3
2. Processing Model ...............................................3 2. Processing Model ...............................................3
3. Trust Model ....................................................4 3. Trust Model ....................................................4
4. Component Structure ............................................4 4. Component Structure ............................................5
4.1 Voucher Component ..........................................4
4.2 Promise Component ..........................................5
5. Syntax Overview and Examples ...................................7 5. Syntax Overview and Examples ...................................7
6. Syntax and Semantics ...........................................8 6. Syntax and Semantics ...........................................8
6.1 <Voucher> ..................................................8 6.1 <Voucher> ..................................................8
6.2 <Provider> .................................................8 6.2 <Title> ....................................................8
6.3 <Issuer> ...................................................9 6.3 <Description> ..............................................9
6.4 <Promise> ..................................................9 6.4 <Provider> .................................................9
6.4.1 <Title> .................................................10 6.5 <Issuer> ...................................................9
6.4.2 <Description> ...........................................10 6.6 <Holder> ..................................................10
6.4.3 <Value> .................................................10 6.7 <Collector> ...............................................10
6.4.3.1 <Ratio> ...............................................11 6.8 <Value> ...................................................11
6.4.3.2 <Fixed> ...............................................12 6.8.1 <Ratio> .................................................12
6.4.4 <ValidPeriod> ...........................................12 6.8.2 <Fixed> .................................................12
6.4.5 <Merchandise> ...........................................13 6.9 <Merchandise> .............................................13
6.4.6 <Conditions> ............................................13 6.10 <ValidPeriod> ............................................14
6.5 <Holder> ..................................................14 6.11 <Conditions> .............................................14
7. Schemas .......................................................14 7. Schemas .......................................................14
8. VTS Schema Example ............................................16 8. VTS Schema Example ............................................16
9. Security Considerations .......................................17 9. Security Considerations .......................................17
10. Acknowledgments ...............................................17 10. References ....................................................17
11. References ....................................................17 11. Author's Address ..............................................18
12. Author's Address ..............................................17
1. Introduction 1. Introduction
This document, XML Voucher, specifies rules for defining voucher This document, XML Voucher, specifies rules for defining voucher
properties in XML syntax. The motivation and background of the properties in XML syntax. The motivation and background of the
specification are described in [GVT]. specification are described in [GVT].
A voucher is a logical entity that represents a certain right and A voucher is a logical entity that represents a certain right and
is logically managed by the Voucher Trading System (VTS). A voucher is logically managed by the Voucher Trading System (VTS). A voucher
is generated by the issuer, traded among users, and finally 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 Voucher
Component, which defines voucher meaning and processing rules in Component, which defines voucher meaning and processing rules in
XML syntax [XML]. A Voucher Component defines the properties that XML syntax [XML]. A Voucher Component define the properties that
must be satisfied to allow the voucher to be processed by VTS or must be satisfied to allow the voucher to be processed by VTS or
other trading systems, e.g., wallet or merchant system. VTS other trading systems, e.g., wallet or merchant system. VTS
definitions and models are also defined in [GVT]. definitions and models are also defined in [GVT].
Note: This document uses "voucher" as an "instance of voucher" Note: This document uses "voucher" as an "instance of voucher"
whose meaning is defined by Voucher Component. In other words, whose meaning is defined by Voucher Component. In other words,
multiple vouchers can be issued and managed by the VTS using the multiple vouchers can be issued and managed by the VTS using the
same Voucher Component. same Voucher Component.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 3, line 27 skipping to change at page 3, line 45
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 smart-card-based offline VTS is often preferred,
whereas for bonds or securities, the centralized online VTS is whereas for bonds or securities, the centralized online VTS is
preferred. It is impractical to define standard protocols for preferred. It is impractical to define standard protocols for
issuing, transferring, or redeeming vouchers at this moment. issuing, transferring, or redeeming vouchers at this moment.
To provide implementation flexibility, this document assumes a To provide implementation flexibility, this document assumes a
modular wallet architecture that allows multiple VTS to be added as modular wallet architecture that allows multiple VTS to be added as
plug-ins. In 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, i.e., Voucher
Component and VTS API specifications, are standardized (Figure 1). 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].
Sender wallet/Issuing system Receiver wallet/Collecting system Sender wallet/Issuing system Receiver wallet/Collecting system
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
| | | | | | | |
| | Voucher Component | | | | Voucher Component | |
| | (Specifies Issuer, Promise, Holder, and VTS Provider) | | | | (Specifies VTS Provider and Promise) | |
| |-------------------------------------------------------->| | | |-------------------------------------------------------->| |
| | | | | | | | | | | |
| | Intention to receive and payment (option) | | | | Intention to receive and payment (option) | |
| |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | | | |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | Issue/transfer/ VTS | | VTS Register | | | | Issue/transfer/ VTS | | VTS Register | |
| | redeem request plug-in | plug-in 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
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 will be published as a separate document.
3. Trust Model 3. Trust Model
A voucher is trusted if the Issuer and VTS Provider are trusted, A voucher is trusted if the Issuer and VTS Provider are trusted,
since the Issuer is responsible for the contents of the voucher and since the Issuer is responsible for the contents of the voucher and
the VTS Provider is responsible for preventing ownership from being the VTS Provider is responsible for preventing ownership from being
assigned to multiple users. assigned to multiple users.
The trust level required for Issuer and VTS Provider depends on the The trust level required for Issuer and VTS Provider depends on the
type (or Promise) of the voucher. To provide the information needed type (or Promise) of the voucher. To provide the information needed
for verification, the conditions of Issuer and VTS Provider are for verification, the conditions of Issuer and VTS Provider are
specified in the Voucher Component, and given as input to the specified in the Voucher Component, and given as input to the
verifier, e.g., wallet system or other software. The trust of a 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.
The Voucher Component is usually delivered from the trusted VTS The Voucher Component is usually delivered from the trusted VTS
Provider, Issuer or trusted third party using a secure Provider, Issuer or trusted third party using a secure
communication channel, such as [XMLDSIG], [TLS], or communication channel, such as [XMLDSIG], [TLS], or [IPSEC].
[IPSEC]. Delivery of the Voucher Component is beyond the scope of Delivery of the Voucher Component is beyond the scope of this
this document. document.
Note: The Voucher Component does not have to be sent from the Note: The Voucher Component does not have to be sent from the
sender of the voucher. Note also that a set of trusted Voucher sender of the voucher. Note also that a set of trusted Voucher
Components can be downloaded before conducting a transaction. Components can be downloaded before conducting a transaction.
4. Component Structure 4. Component Structure
4.1 Voucher Component
A Voucher Component provides VTS Provider information, and basic
properties for representing a voucher, i.e., Issuer, Promise, and
Holder. Implementation-specific properties are often required for
authenticating VTS Provider, Issuer and Holder. These
implementation-specific properties of the VTS can be attached as
child elements using [XML-ns].
The Voucher Component contains Provider Component, Issuer
Component, Promise Component, and Holder Component as follows:
Provider Component
Provides properties that specify which VTS Provider (or VTS
plug-in) can be used for trading the voucher.
Issuer Component
Provides properties specifying the Issuer of the vouchers. This
is optional and can be omitted if the Issuer role is delegated to
the VTS Provider.
Promise Component
Provides properties used by the application system of VTS, e.g.,
wallet system, merchant system. The Promise Component is
transparent to the VTS and is described in Section 4.2.
Holder Component The Voucher Component provides the information needed to identify
Provides properties that specify the Holder of the vouchers. This
is optional and can be omitted if the vouchers are transferable.
4.2 Promise Component
The Promise Component provides the information needed to identify
the monetary value or merchandize rendered when the voucher is the monetary value or merchandize rendered when the voucher is
redeemed. It includes: redeemed. 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
o Restrictions applied to the voucher o Restrictions applied to the voucher
- Participants (VTS Provider, Issuer, Holder, and Collector)
- Objects (merchandise) to be claimed - Objects (merchandise) to be claimed
- Time when valid (validity period) - Time when valid (validity period)
- Others - Others
The Promise 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 Promise Component contains the Title Component, Description The Voucher Component contains the Title Component, Description
Component, Value Component, ValidPeriod Component, Merchandise Component, Provider Component, Issuer Component, Holder Component,
Component, and Condition Component as follows: 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 entities stored in a wallet system. the entities stored in a wallet system.
Description Component Description Component
Provides a short description of the voucher. This is mainly for Provides a short description of the voucher. This is mainly for
listing the entities stored in a wallet system. listing the entities stored in a wallet system.
Provider Component
Provides restrictions on which VTS Provider (or VTS plug-in) can
be used for trading the voucher.
Issuer Component
Provides restrictions on the Issuer of the voucher.
Holder Component
Provides restrictions on the Holder of the voucher.
Collector Component
Provides restrictions on the Collector of the voucher.
Value Component 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, i.e., fixed and ratio values. For a fixed value, the
currency and the figure is specified. For a ratio value, the currency and the figure is specified. For a ratio value, the
discount ratio of the corresponding merchandize is specified. discount 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 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 be used repeatedly. can be used repeatedly.
ValidPeriod Component
Provides restrictions on the validity period of the voucher,
i.e., start date and end date.
Merchandise Component Merchandise Component
Provides restrictions on the object to be claimed. Provides restrictions on the object to be claimed.
Domain-specific meaning of the voucher, e.g., reference number of Domain-specific meaning of the voucher, e.g., reference number of
the merchandize or seat number for an event ticket, is specified the merchandize or seat number for an event ticket, is specified
to identify the merchandize rendered when the voucher is to identify the merchandize rendered when the voucher is
redeemed. redeemed.
ValidPeriod Component
Provides restrictions on the validity period of the voucher,
i.e., 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 natural language form. voucher in 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.
+----------------+--------------------------------+---------------+ +----------------+--------------------------------+---------------+
skipping to change at page 7, line 16 skipping to change at page 7, line 16
This section provides an overview and examples of Voucher This section provides an overview and examples of Voucher
Component. The formal syntax and semantics are found in Sections 6 Component. The formal syntax and semantics are found in Sections 6
and 7. and 7.
Voucher Components are represented by the <Voucher> element which Voucher Components are represented by the <Voucher> element which
has the following structure (where "?" denotes zero or one has the following structure (where "?" denotes zero or one
occurrence): occurrence):
<Voucher> <Voucher>
(Title)
(Description)?
(Provider) (Provider)
(Issuer)? (Issuer)?
<Promise> (Holder)?
(Title)? (Collector)?
(Description)?
(Value) (Value)
(ValidPeriod)?
(Merchandise)? (Merchandise)?
(ValidPeriod)?
(Conditions)? (Conditions)?
</Promise>
(Holder)?
</Voucher> </Voucher>
An example of a Voucher Component is described below. This is an An example of a Voucher Component is described below. This is an
example of a five dollar discount coupon for specific merchandize, example of a five dollar discount coupon for specific merchandize,
a book with ISBN number 0071355014. The coupon is valid from April a book with ISBN number 0071355014. The coupon is valid from April
1st in 2001 to March 31st in 2002. To claim this offer, one voucher 1st in 2001 to March 31st in 2002. To claim this offer, one voucher
must be spent. must be spent.
<?xml version="1.0"?> <?xml version="1.0"?>
<Voucher xmlns="http://www.ietf.org/rfc/rfcXXXX" <Voucher xmlns="http://www.ietf.org/rfc/rfcXXXX"
xmlns:vts="http://www.example.com/vts"> xmlns:vts="http://www.example.com/vts">
<Provider name="Voucher Wallet 2001"> <Title>IOTP Book Coupon</Title>
<vts:Version>2.31</vts:Version> <Description>$5 off IOTP Book</Description>
<Provider name="Voucher Exchanger 2002">
<vts:Version>VE2.31</vts:Version>
</Provider> </Provider>
<Issuer name="Alice Book Center, Ltd."> <Issuer name="Alice Book Center, Ltd.">
<vts:KeyInfo>1DA8DFCF95521014BBB7171B95545E8D61AE803F <vts:KeyInfo>
1DA8DFCF95521014BBB7171B95545E8D61AE803F
</vts:KeyInfo> </vts:KeyInfo>
</Issuer> </Issuer>
<Promise> <Collector name="Alice Book Center, Ltd."/>
<Title>IOTP Book Coupon</Title>
<Description>$5 off IOTP Book</Description>
<Value type="discount" spend="1"> <Value type="discount" spend="1">
<Fixed amount="5" currency="USD"/> <Fixed amount="5" currency="USD"/>
</Value> </Value>
<ValidPeriod start="2001-04-01" end="2002-03-31"/>
<Merchandise> <Merchandise>
<bk:BookID xmlns:bk="http://www.example.com/book" <bk:Book xmlns:bk="http://www.example.com/bk"
bk:ISDN="0071355014"/> bk:isbn="0071355014"/>
</Merchandise> </Merchandise>
<Conditions>It can be claimed only at Alice Book Center. <ValidPeriod start="2001-04-01" end="2002-03-31"/>
<Conditions>
The value of this coupon is subject to tax.
</Conditions> </Conditions>
</Promise>
</Voucher> </Voucher>
6. Syntax and Semantics 6. Syntax and Semantics
The general structure of an XML voucher is described in Component The general structure of an XML voucher is described in Component
Structure (section 4). This section details the Voucher Component Structure (section 4). This section details the Voucher Component
features. Features described in this section MUST be implemented features. Features described in this section MUST be implemented
unless otherwise indicated. The syntax is defined via unless otherwise indicated. The syntax is defined via
[XML-Schema-1] [XML-Schema-2]. For clarity, unqualified elements in [XML-Schema-1] [XML-Schema-2]. For clarity, unqualified elements in
schema definitions are in the XML schema namespace: schema definitions are in the XML schema namespace:
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
References to the XML Voucher schema defined herein use the prefix References to XML Voucher schema defined herein use the prefix
"gvl" and are in the namespace: "gvl" and are in the namespace:
xmlns:gvl="http://www.ietf.org/rfc/rfcXXXX.txt" xmlns:gvl="http://www.ietf.org/rfc/rfcXXXX.txt"
This namespace is also used for unqualified elements in voucher [If this document is published as an RFC, "XXXX" will be replaced by
examples. the RFC number.] This namespace is also used for unqualified elements
in voucher examples.
6.1 <Voucher> 6.1 <Voucher>
The <Voucher> element contains <Provider> and <Promise> elements The <Voucher> element contains <Title>, <Provider>, and <Value>
and optionally contains <Issuer> and <Holder> elements. These elements and optionally contains <Description>, <Issuer>, <Holder>,
<Collector>, <ValidPeriod>, and <Condition> elements. These
sub-elements are defined in the following sections. sub-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: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:Promise"/>
<element ref="gvl:Holder" 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> </sequence>
</complexType> </complexType>
6.2 <Provider> 6.2 <Title>
The <Provider> element may contain any elements that are used to 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 specify or restrict the VTS Provider of the voucher. The
sub-elements contained in this element depend on the implementation sub-elements contained in this element depend on the implementation
of the VTS. of 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 identify and/or authenticate the VTS Provider when the VTS plug-in is
is registered. These implementation-specific elements of the VTS registered (See Section 7 of [VTS-API]). These
can be extended using [XML-ns]. An example of such schema implementation-specific elements of the VTS can be extended using
definition is described in Section 8. [XML-ns]. An example of such schema definition is described in
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"> <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" use="required"/> <attribute name="name" type="string"/>
</complexType> </complexType>
6.3 <Issuer> 6.5 <Issuer>
The <Issuer> element may contain any element that is used to The <Issuer> element may contain any element that is used to specify
specify or restrict the Issuer of the voucher. The sub-elements or restrict the Issuer of the voucher.
contained in this element depend on the implementation of the
VTS. An implementation of a VTS often requires it to describe the
authentication data of the Issuer. These implementation-specific
elements of the VTS can be extended using [XML-ns].
The <Issuer> element has a string-type "name" attribute that is The Issuer of the voucher is generally managed by the VTS [VTS-API].
used to specify the name of the Issuer. 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: 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.2. The <RoleType> element type is defined in Section 6.4.
If the <Issuer> element is omitted, it MUST be interpreted that the If the <Issuer> element is omitted, it MUST be interpreted that there
issuer role is delegated to the VTS Provider. are no restrictions on the Issuer. The issuer role (responsibility
for the contents of the voucher) is delegated to the VTS Provider.
6.4 <Promise> 6.6 <Holder>
The <Promise> element contains a <Value> element and optionally The <Holder> element may contain any elements that is used to specify
<Title>, <Description>, <ValuePeriod>, and <Condition> or restrict the Holder of the voucher.
elements. These sub-elements are defined in the following sections.
The <Promise> element is defined by the following schema: 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].
<element name="Promise" type="gvl:PromiseType"/> The <Holder> element has a string-type "name" attribute that is used
<complexType name="PromiseType"> to specify the name of the Holder.
<sequence>
<element ref="gvl:Title" minOccurs="0"/>
<element ref="gvl:Description" minOccurs="0"/>
<element ref="gvl:Value"/>
<element ref="gvl:ValidPeriod" minOccurs="0"/>
<element ref="gvl:Merchandise" minOccurs="0"/>
<element ref="gvl:Conditions" minOccurs="0"/>
</sequence>
</complexType>
6.4.1 <Title> The <Holder> element is defined by the following schema:
The <Title> element contains a simple text title of the voucher. <element name="Holder" type="gvl:RoleType"/>
This is mainly for listing the entities stored in a wallet system. The <RoleType> element type is defined in Section 6.4.
The <Title> element has no attribute. If the <Holder> element is omitted, it MUST be interpreted that there
are no restrictions on the Holder.
The <Title> element is defined by the following schema: 6.7 <Collector>
<element name="Title" type="string"/> The <Collector> element may contain any elements that is used to
specify or restrict the Collector of the voucher.
6.4.2 <Description> There is no need to specify the Collector of the voucher using this
element if there are no restrictions on the Collector.
An implementation of a VTS may use this element to describe the
authentication data and/or qualification information of the
Collector. This implementation-specific information can be extended
as sub-elements using [XML-ns].
The <Description> element contains a simple text description of the The <Collector> element has a string-type "name" attribute that is
voucher. This is mainly for listing the entities stored in a used to specify the name of the Collector.
wallet system.
The <Description> element has no attribute. The <Collector> element is defined by the following schema:
The <Description> element is defined by the following schema: <element name="Collector" type="gvl:RoleType"/>
The <RoleType> element type is defined in Section 6.4.
<element name="Description" type="string"/> If the <Collector> element is omitted, it MUST be interpreted that
there are no restrictions on the Collector.
6.4.3 <Value> 6.8 <Value>
The <Value> element optionally contains a <Fixed> or a <Ratio> The <Value> element optionally contains a <Fixed> or a <Ratio>
element but not both. These sub-elements are defined in the element but not both. These sub-elements are defined in the
following sections. following 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.
skipping to change at page 11, line 16 skipping to change at page 12, line 6
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, services, or monetary value specified. For example, if "n" goods, services, or monetary value specified. For example, if "n"
(>0) is specified, goods etc. can be claimed in exchange for "n (>0) is specified, goods etc. can be claimed in exchange for "n
sheets of" vouchers. (Note: Multiple vouchers for the same Voucher sheets of" vouchers. (Note: Multiple vouchers for the same Voucher
Component must exist in this case.) If "0" is specified, it can be Component must exist in this case.) If "0" is specified, it can be
used repeatedly. used repeatedly.
If the "spend" attribute is omitted or the whole element is omitted, If the "spend" attribute is omitted or the whole element is omitted,
it MUST be interpreted that "0" is specified for the "spend" it MUST be 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"/>
skipping to change at page 11, line 46 skipping to change at page 12, line 36
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.4.3.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 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.4.3.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 optionally a "decimalPower" attribute as follows: and 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 ISO currency code [ISO4217]. For example, for US dollars letter ISO currency code [ISO4217]. For example, for US dollars
it 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.
skipping to change at page 12, line 42 skipping to change at page 13, line 31
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 specifed 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 "amount" attribute and the "decimalPower" attribute is omitted. the "amount" attribute and the "decimalPower" attribute is omitted.
The <FixedValueType> type is defined by the following definition: The <FixedValueType> type is defined by the following definition:
<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="Integer" default="0"/> <attribute name="decimalPower" type="short" default="0"/>
</complexType> </complexType>
6.4.4 <ValidPeriod> 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].
The <Merchandise> element does not have any attribute.
The <Merchandise> element is defined by the following schema:
<element name="Merchandise" type="gvl:MerchandiseType"/>
<complexType name="MerchandiseType" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
If the <Merchandise> element is omitted, it will be generally
interpreted that there is no restriction on the merchandise when
using the voucher.
6.10 <ValidPeriod>
The <VaridPeriod> element does not contain any contents. The <VaridPeriod> 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"/>
skipping to change at page 13, line 16 skipping to change at page 14, line 29
</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 voucher is valid on any date up to the date (inclusive) the voucher is valid on any date up to the date (inclusive)
specified by the end attribute. If the "end" attribute is omitted, specified by the end attribute. If the "end" attribute is omitted,
it MUST be interpreted that the voucher is valid from the start it MUST be interpreted that the voucher is valid from the start
attribute with no expiry. If neither attribute is specified or the attribute with no expiry. If neither attribute is specified or the
whole element is omitted, it MUST be interpreted that the voucher whole element is omitted, it MUST be interpreted that the voucher
is valid at any time. is valid at any time.
6.4.5 <Merchandise> 6.10 <Conditions>
The <Merchandise> element may contain any elements used to specify
or restrict the goods or services rendered when the voucher is
redeemed. The sub-elements contained in this element depend on the
application of the voucher and are left to the other
domain-specific specifications. Domain-specific elements can be
extended as sub-elements using [XML-ns].
The <Merchandise> element does not have any attribute.
The <Merchandise> element is defined by the following schema:
<element name="Merchandise" type="gvl:MerchandiseType"/>
<complexType name="MerchandiseType" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
If the <Merchandise> element is omitted, it will be generally
interpreted that there is no restriction on the merchandise when
using the voucher.
6.4.6 <Conditions>
The <Conditions> element may contain any element used to specify The <Conditions> element may contain any element used to specify
any other restrictions or conditions applied that limit the use of any other restrictions or conditions applied that limit the use of
the voucher. The sub-elements contained in this element the voucher. The sub-elements contained in this element are
depend on the application of the voucher and are left to the depending on the application of the voucher and are left to the
other domain-specific specifications. Domain-specific elements can other domain-specific specifications. Domain-specific elements can
be extended as sub-elements using [XML-ns]. be extended as sub-elements using [XML-ns].
The <Conditions> element does not have any attribute. The <Conditions> element does not have any attribute.
The <Conditions> element is defined by the following schema: The <Conditions> element is defined by the following schema:
<element name="Conditions" type="gvl:ConditionsType"/> <element name="Conditions" type="gvl:ConditionsType"/>
<complexType name="ConditionsType" mixed="true"> <complexType name="ConditionsType" mixed="true">
<sequence> <sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
If the <Conditions> element is omitted, it will be generally If the <Conditions> element is omitted, it will be generally
interpreted that there are no other restrictions or conditions on interpreted that there are no other restrictions or conditions on
using the voucher. using the voucher.
6.5 <Holder>
The <Holder> element may contain any element used to specify or
restrict the Holder of the voucher. The sub-elements contained in
this element depend on the implementation of the VTS. An
implementation of a VTS often requires this element to describe the
authentication data of the Holder. These implementation-specific
elements of the VTS can be extended using [XML-ns].
The <Holder> element has a string-type "name" attribute that is
used to specify the name of the Holder. Note: Null string ("") MAY
be specified for the name of the Holder if the name of the Holder
is not given.
The <Holder> element is defined by the following schema:
<element name="Holder" type="gvl:RoleType"/>
The <RoleType> element type is defined in Section 6.2.
If the <Holder> element is omitted, it MUST be interpreted that the
voucher is transferable. (Note: Even for transferable vouchers,
this element may be used by the VTS depending on implementation
needs.)
7. Schemas 7. Schemas
The collected XML schema specification is: The collected XML schema specification is:
<?xml version="1.0"?> <?xml version="1.0"?>
<schema <schema
targetNamespace="http://www.ietf.org/rfc/rfcXXXX" targetNamespace="http://www.ietf.org/rfc/rfcXXXX"
xmlns:gvl="http://www.ietf.org/rfc/rfcXXXX" xmlns:gvl="http://www.ietf.org/rfc/rfcXXXX"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<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: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:Promise"/>
<element ref="gvl:Holder" minOccurs="0"/> <element ref="gvl:Holder" minOccurs="0"/>
</sequence> <element ref="gvl:Collector" minOccurs="0"/>
</complexType>
<element name="Provider" type="gvl:RoleType"/>
<element name="Issuer" type="gvl:RoleType"/>
<element name="Holder" type="gvl:RoleType"/>
<complexType name="RoleType">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="string" use="required"/>
</complexType>
<element name="Promise" type="gvl:PromiseType"/>
<complexType name="PromiseType">
<sequence>
<element ref="gvl:Title" minOccurs="0"/>
<element ref="gvl:Description" minOccurs="0"/>
<element ref="gvl:Value"/> <element ref="gvl:Value"/>
<element ref="gvl:ValidPeriod" minOccurs="0"/>
<element ref="gvl:Merchandise" minOccurs="0"/> <element ref="gvl:Merchandise" minOccurs="0"/>
<element ref="gvl:ValidPeriod" minOccurs="0"/>
<element ref="gvl:Conditions" minOccurs="0"/> <element ref="gvl:Conditions" minOccurs="0"/>
</sequence> </sequence>
</complexType> </complexType>
<element name="Title" type="string"/> <element name="Title" type="string"/>
<element name="Description" 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"/> <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"/>
skipping to change at page 16, line 12 skipping to change at page 16, line 25
<restriction base="float"> <restriction base="float">
<maxInclusive value="100"/> <maxInclusive value="100"/>
</restriction> </restriction>
</simpleType> </simpleType>
</attribute> </attribute>
</complexType> </complexType>
<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="Integer" default="0"/> <attribute name="decimalPower" type="short" default="0"/>
</complexType>
<element name="ValidPeriod" type="gvl:ValidPeriodType"/>
<complexType name="ValidPeriodType">
<attribute name="start" type="dateTime"/>
<attribute name="end" type="dateTime"/>
</complexType> </complexType>
<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>
<element name="ValidPeriod" type="gvl:ValidPeriodType"/>
<complexType name="ValidPeriodType">
<attribute name="start" type="dateTime"/>
<attribute name="end" type="dateTime"/>
</complexType>
<element name="Conditions" type="gvl:ConditionsType"/> <element name="Conditions" type="gvl:ConditionsType"/>
<complexType name="ConditionsType" mixed="true"> <complexType name="ConditionsType" mixed="true">
<sequence> <sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</schema> </schema>
8. VTS Schema Example 8. VTS Schema Example
skipping to change at page 17, line 11 skipping to change at page 17, line 25
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
Security issues for delivering Voucher Components are discussed in Security issues for delivering Voucher Components are discussed in
Section 3. Section 3.
10. Acknowledgement 10. References
(tbs)
11. References
[ECML] J. W. Parsons, "Electronic Commerce Modeling Language (ECML) [ECML] J. W. Parsons, "Electronic Commerce Modeling Language (ECML)
Version 2 Specification", draft-ietf-trade-ecml2-spec-00.txt, Version 2 Specification", draft-ietf-trade-ecml2-spec-02.txt,
February 2001. October 2001.
[GVT] K. Fujimura, "Requirements for Generic Voucher Trading", [GVT] K. Fujimura, "Requirements for Generic Voucher Trading",
draft-ietf-trade-drt-requirements-02.txt, February 2001. draft-ietf-trade-drt-requirements-02.txt, February 2001.
[IPSEC] R. Thayer, N. Doraswamy, and R. Glenn, "IP Security Document [IPSEC] R. Thayer, N. Doraswamy, and R. Glenn, "IP Security Document
Roadmap", RFC2411, November 1998 Roadmap", RFC2411, November 1998
[ISO4217] "Codes for the representation of currencies and funds", [ISO4217] "Codes for the representation of currencies and funds",
ISO 4217, 1995. ISO 4217, 1995.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246,
January 1999. January 1999.
[VTS-API] M. Terada and K. Fujimura, "Voucher Trading System
Application Programming Interface (VTS-API)",
draft-ietf-trade-voucher-vtsapi-00.txt, July 2001.
[XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A
W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000. W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000.
[XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature [XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature
Syntax and Processing", draft-ietf-xmldsig-core-2-00.txt, April Syntax and Processing", draft-ietf-xmldsig-core-2-02.txt, October
2001. 2001.
[XML-ns] "Namespaces in XML", A W3C Recommendation, [XML-ns] "Namespaces in XML", A W3C Recommendation,
<http://www.w3.org/TR/REC-xml-names>, January 1999. <http://www.w3.org/TR/REC-xml-names>, January 1999.
[XML-Schema-1] H. Thompson, D. Beech, M. Maloney, and [XML-Schema-1] H. Thompson, D. Beech, M. Maloney, and
N. Mendelsohn, "XML Schema Part 1: Structures W3C Recommendation.", N. Mendelsohn, "XML Schema Part 1: Structures W3C Recommendation.",
<http://www.w3.org/TR/xmlschema-1/>, May 2001. <http://www.w3.org/TR/xmlschema-1/>, May 2001.
[XML-Schema-2] P. Biron and A Malhotra, "XML Schema Part 2: [XML-Schema-2] P. Biron and A Malhotra, "XML Schema Part 2:
Datatypes W3C Recommendation.", Datatypes W3C Recommendation.",
<http://www.w3.org/TR/xmlschema-2/>, May 2001. <http://www.w3.org/TR/xmlschema-2/>, May 2001.
12. Author's Address 11. Author's Address
Ko Fujimura and Masayuki Terada Ko Fujimura and Masayuki Terada
NTT Corporation NTT Corporation
1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN
Phone: +81-(0)468-59-3814 Phone: +81-(0)468-59-3814
Fax: +81-(0)468-59-2241 Fax: +81-(0)468-59-2241
Email: fujimura@isl.ntt.co.jp, terada@isl.ntt.co.jp Email: fujimura@isl.ntt.co.jp, terada@isl.ntt.co.jp
 End of changes. 

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