draft-ietf-trade-voucher-lang-05.txt   draft-ietf-trade-voucher-lang-06.txt 
Trade Working Group February 2003 Trade Working Group February 2004
INTERNET-DRAFT Ko Fujimura INTERNET-DRAFT Ko Fujimura
NTT
Masayuki Terada Masayuki Terada
Expires: August 2003 NTT NTT DoCoMo
Expires: August 2004
XML Voucher: Generic Voucher Language XML Voucher: Generic Voucher Language
<draft-ietf-trade-voucher-lang-05.txt> <draft-ietf-trade-voucher-lang-06.txt>
Status of This Document Status of This Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 49 skipping to change at page 1, line 51
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.
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Acknowledgements Acknowledgements
The following persons, in alphabetic order, contributed substantially The following persons, in alphabetic order, contributed substantially
to the material herein: to the material herein:
Donald Eastlake 3rd Donald Eastlake 3rd
Ian Grigg Ian Grigg
Renato Iannella Renato Iannella
Yoshiaki Nakajima Yoshiaki Nakajima
skipping to change at page 3, line 9 skipping to change at page 3, line 9
10. Normative References ..........................................17 10. Normative References ..........................................17
11. Informational References ......................................18 11. Informational References ......................................18
12. Author's Address ..............................................18 12. Author's Address ..............................................18
Full Copyright Statement ..........................................19 Full Copyright Statement ..........................................19
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 [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 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 define 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 [VTS].
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC 2119] this document are to be interpreted as described in [RFC 2119]
skipping to change at page 7, line 35 skipping to change at page 7, line 35
(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 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="urn:ietf:params:xml:schema: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>
skipping to change at page 8, line 23 skipping to change at page 8, line 23
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 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="urn:ietf:params:xml:schema: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], using the namespace identifier 'ietf' defined by [URN-NS-IETF]
and extended by [XML-Registry]. 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>
skipping to change at page 13, line 43 skipping to change at page 13, line 43
6.9 <Merchandise> 6.9 <Merchandise>
The <Merchandise> element may contain any elements used to specify or The <Merchandise> element may contain any elements 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 are depending on the
application of the voucher and are left to the other domain-specific application 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-elements using [XML-ns]. sub-elements using [XML-ns].
This element is intended to be interpreted by a collecting system.
An implementation of a wallet system does not have to use this
element. Any restrictions applied should also be described in the
<Description> element or the <Conditions> elements in natural
language form to enable users to check the restrictions.
The <Merchandise> element does not have any attribute. The <Merchandise> element 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>
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> 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:
skipping to change at page 14, line 29 skipping to change at page 14, line 31
</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.10 <Conditions> 6.11 <Conditions>
The <Conditions> element may contain any element used to specify The <Conditions> element contains any other restrictions or
any other restrictions or conditions applied that limit the use of conditions applied. This is intended to cover contracts between the
the voucher. The sub-elements contained in this element are issuer and holder of the voucher in natural language form.
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 <Conditions> element does not have any attribute. An implementation of a wallet system SHOULD provide a means of
displaying the text in this element.
The <Conditions> element is defined by the following schema: The <Conditions> element has no attribute.
<element name="Conditions" type="gvl:ConditionsType"/> The <Conditions> element is defined by the following schema:
<complexType name="ConditionsType" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
If the <Conditions> element is omitted, it will be generally <element name="Conditions" type="string"/>
interpreted that there are no other restrictions or conditions on
using the voucher.
7. IANA Considerations 7. IANA Considerations
This document calls for IANA to register a new XML schema with the This document uses URNs to describe XML namespaces and XML schemas
URN. The registation form [XML-Registry] for this is below: conforming to a registry mechanism described in [XML-Registry].
Two URI assignments are requested.
URI Registration request for the vts-lang namespace:
urn:ietf:params:xml:schema:vts-lang
Registrant Contact URI: urn:ietf:params:xml:ns:vts-lang
See the "Author's Address" section of this document.
XML Registrant Contact: See the "Author's Address" section of this
document.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the vts-lang XML schema:
URI: urn:ietf:params:xml:schema:vts-lang
Registrant Contact: See the "Author's Address" section of this
document.
XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<schema <schema
targetNamespace="urn:ietf:params:xml:schema:vts-lang" targetNamespace="urn:ietf:params:xml:ns:vts-lang"
xmlns:gvl="urn:ietf:params:xml:schema: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"
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: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"/>
skipping to change at page 16, line 51 skipping to change at page 16, line 54
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
<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="gvl:ConditionsType"/> <element name="Conditions" type="string"/>
<complexType name="ConditionsType" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</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"?>
skipping to change at page 17, line 31 skipping to change at page 17, line 29
<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
Security issues for delivering Voucher Components are discussed in The VTS must provide a means of preventing forgery, alteration,
Section 3. duplicate-redemption, reproduction of a voucher, and non-repudiation
of transactions as described in Section 3.2 of [VTS]. These security
requirements, however, mainly follow the VTS plug-ins and their
protocols. This document assumes that the VTS plug-ins are trusted
and installed by some means, e.g., manually checked like other
download applications.
The Voucher Component, however, defines restrictions on VTS Provider
(or VTS plug-in), and if this information is altered, incorrect VTS
plug-ins not accepted by the issuer could be used, and a forged
voucher could be verified as if it were valid. To prevent this
situation, the Voucher Component should be acquired securely, e.g.,
downloaded from a trusted party using a secure communication channel,
such as [TLS], or [IPSEC], or secured by the digital signature of a
trusted party.
10. Normative References 10. Normative References
[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.
[URN] R. Moats, "URN Syntax", RFC2141, May 1997. [URN] R. Moats, "URN Syntax", RFC2141, May 1997.
[URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents", [URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents",
RFC2648, August 1999. RFC2648, August 1999.
[XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A
W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000. W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000.
[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-Registry] M. Mealing, "The IETF XML Registry", [XML-Registry] M. Mealling, "The IETF XML Registry", RFC3688
draft-mealling-iana-xmlns-registry-04, June 2002. In RFC Editor January 2004.
queue.
[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.
11. Informational References 11. Informational References
[GVT] K. Fujimura, "Requirements and Design for Voucher Trading [VTS] K. Fujimura, D Eastlake, "Requirements and Design for Voucher
System (VTS)", draft-ietf-trade-drt-requirements-04.txt, July Trading System (VTS)", RFC3506, March 2003.
2002. In RFC Editor queue.
[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
[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 [VTS-API] M. Terada and K. Fujimura, "Voucher Trading System
Application Programming Interface (VTS-API)", Application Programming Interface (VTS-API)",
draft-ietf-trade-voucher-vtsapi-05.txt, February 2003. draft-ietf-trade-voucher-vtsapi-06.txt, February 2004.
[XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature [XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature
Syntax and Processing", RFC3275, March 2002. Syntax and Processing", RFC3275, March 2002.
12. Author's Address 12. Author's Address
Ko Fujimura and Masayuki Terada 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-3814 Phone: +81-(0)46-859-3814
Fax: +81-(0)46-859-8329 Fax: +81-(0)46-859-8329
Email: fujimura@isl.ntt.co.jp, terada@isl.ntt.co.jp Email: fujimura@isl.ntt.co.jp
Masayuki Terada
NTT DoCoMo, Inc.
3-5 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-8536 JAPAN
Phone: +81-(0)46-840-3809
Fax: +81-(0)46-840-3364
Email: te@mml.yrp.nttdocomo.co.jp
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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