idnits 2.17.1 draft-ietf-trade-voucher-lang-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 155 has weird spacing: '...request plug...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 116, but not defined == Unused Reference: 'ECML' is defined on line 860, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 874, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-trade-ecml2-spec-03 == Outdated reference: A later version (-04) exists of draft-ietf-trade-drt-requirements-03 ** Downref: Normative reference to an Informational draft: draft-ietf-trade-drt-requirements (ref. 'GVT') ** Obsolete normative reference: RFC 2411 (ref. 'IPSEC') (Obsoleted by RFC 6071) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2141 (ref. 'URN') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. 'URN-NS-IETF') == Outdated reference: A later version (-06) exists of draft-ietf-trade-voucher-vtsapi-01 ** Downref: Normative reference to an Informational draft: draft-ietf-trade-voucher-vtsapi (ref. 'VTS-API') -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-ns' == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-Schema-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-Schema-2' Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Ko Fujimura 2 Masayuki Terada 3 Expires: December 2002 NTT 5 XML Voucher: Generic Voucher Language 6 8 Status of This Document 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this document is unlimited. Please send comments to 30 the TRADE working group at , which may 31 be joined by sending a message with subject "subscribe" to . 34 Discussions of the TRADE working group are archived at 35 http://lists.elistx.com/archives/ietf-trade. 37 Abstract 39 This document specifies rules for defining voucher properties in XML 40 syntax. A voucher is a logical entity that represents a right to 41 claim goods or services. A voucher can be used to transfer a 42 wide-range of electronic-values, including coupons, tickets, loyalty 43 points, and gift certificates, which are often necessary to process 44 in the course of payment and/or delivery transactions. 46 Acknowledgements 48 The following persons, in alphabetic order, contributed substantially 49 to the material herein: 51 Donald Eastlake 3rd 52 Ian Grigg 53 Renato Iannella 54 Yoshiaki Nakajima 56 Table of Contents 58 Status of this Memo ...............................................1 59 Abstract ..........................................................1 60 Acknowledgments ...................................................2 61 Table of Contents .................................................2 63 1. Introduction ...................................................3 64 2. Processing Model ...............................................3 65 3. Trust Model ....................................................4 66 4. Component Structure ............................................5 67 5. Syntax Overview and Examples ...................................7 68 6. Syntax and Semantics ...........................................8 69 6.1 ..................................................8 70 6.2 ....................................................9 71 6.3 <Description> ..............................................9 72 6.4 <Provider> .................................................9 73 6.5 <Issuer> ...................................................9 74 6.6 <Holder> ..................................................10 75 6.7 <Collector> ...............................................10 76 6.8 <Value> ...................................................11 77 6.8.1 <Ratio> .................................................12 78 6.8.2 <Fixed> .................................................12 79 6.9 <Merchandise> .............................................13 80 6.10 <ValidPeriod> ............................................14 81 6.11 <Conditions> .............................................14 82 7. IANA Considerations ...........................................14 83 8. VTS Schema Example ............................................17 84 9. Security Considerations .......................................17 85 10. References ....................................................17 86 11. Author's Address ..............................................18 88 Full Copyright Statement ..........................................19 90 1. Introduction 92 This document, XML Voucher, specifies rules for defining voucher 93 properties in XML syntax. The motivation and background of the 94 specification are described in [GVT]. 96 A voucher is a logical entity that represents a certain right and 97 is logically managed by the Voucher Trading System (VTS). A voucher 98 is generated by the issuer, traded among users, and finally 99 collected by the collector using VTS. 101 This document defines the syntax and semantics of Voucher 102 Component, which defines voucher meaning and processing rules in 103 XML syntax [XML]. A Voucher Component define the properties that 104 must be satisfied to allow the voucher to be processed by VTS or 105 other trading systems, e.g., wallet or merchant system. VTS 106 definitions and models are also defined in [GVT]. 108 Note: This document uses "voucher" as an "instance of voucher" 109 whose meaning is defined by Voucher Component. In other words, 110 multiple vouchers can be issued and managed by the VTS using the 111 same Voucher Component. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 115 this document are to be interpreted as described in [RFC 2119] 117 2. Processing Model 119 There are several ways of implementing VTS and technologies are 120 continually changing. For discount coupons or event tickets, for 121 example, the smart-card-based offline VTS is often preferred, 122 whereas for bonds or securities, the centralized online VTS is 123 preferred. It is impractical to define standard protocols for 124 issuing, transferring, or redeeming vouchers at this moment. 126 To provide implementation flexibility, this document assumes a 127 modular wallet architecture that allows multiple VTS to be added as 128 plug-ins. In this architecture, instead of specifying a standard 129 voucher transfer protocol, two specifications, i.e., Voucher 130 Component and VTS-API specifications, are standardized (Figure 1). 132 After sender and receiver agree on what vouchers are to be traded 133 and which VTS is to be used, the issuing system or wallet system 134 requests the corresponding VTS plug-in to permit the issue, 135 transfer, or redeem transactions to be performed via the VTS 136 API. The VTS then rewrites the ownership of the vouchers using the 137 VTS-specific protocol. Finally, a completion event is sent to the 138 wallet systems or issuing/collecting systems. 140 This document describes the Voucher Component specification. The 141 VTS-API specification is defined in [VTS-API]. 143 Sender wallet/Issuing system Receiver wallet/Collecting system 144 +---------------------------+ +---------------------------+ 145 | | | | 146 | | Voucher Component | | 147 | | (Specifies VTS Provider and Promise) | | 148 | |-------------------------------------------------------->| | 149 | | | | | | 150 | | Intention to receive and payment (option) | | 151 | |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | | 152 | | | | | | 153 | | | | | | 154 | | Issue/transfer/ VTS | | VTS Register | | 155 | | redeem request plug-in | plug-in Listener(*1)| | 156 | |------------------>| | | |<------------------| | 157 | | (VTS-API) |<- - - - - - - ->| (VTS-API) | | 158 | | | VTS-specific | | | 159 | | | protocol if VTS | | | 160 | | | is distributed | | | 161 | | Result |<- - - - - - - ->| Notify(*2) | | 162 | |<------------------| | | |------------------>| | 163 +---------------------------+ +---------------------------+ 164 (*1) Registration is optional. Note also that the VTS plug-ins are 165 usually pre-registered when the wallet or collecting system 166 is started. 167 (*2) If a listener is registered. 169 Figure 1. Wallet architecture with VTS plug-ins 171 3. Trust Model 173 A voucher is trusted if the Issuer and VTS Provider are trusted, 174 since the Issuer is responsible for the contents of the voucher and 175 the VTS Provider is responsible for preventing ownership from being 176 assigned to multiple users. 178 The trust level required for Issuer and VTS Provider depends on the 179 type (or Promise) of the voucher. To provide the information needed 180 for verification, the conditions of Issuer and VTS Provider are 181 specified in the Voucher Component, and given as input to the 182 verifier, e.g., wallet system or other software. The trust of a 183 voucher is thus verified through the Voucher Component. This model 184 enables trading partners to verify their trust in the voucher 185 regardless of their trust in the partners. 187 This document assumes that the Voucher Component is the root of 188 trust. If a malicious user could alter the Voucher Component, a 189 forged voucher, could be verified as valid. 191 The Voucher Component is usually delivered from the trusted VTS 192 Provider, Issuer or trusted third party using a secure 193 communication channel, such as [XMLDSIG], [TLS], or [IPSEC]. 194 Delivery of the Voucher Component is beyond the scope of this 195 document. 197 Note: The Voucher Component does not have to be sent from the 198 sender of the voucher. Note also that a set of trusted Voucher 199 Components can be downloaded before conducting a transaction. 201 4. Component Structure 203 The Voucher Component provides the information needed to identify 204 the monetary value or merchandize rendered when the voucher is 205 redeemed. It includes: 207 o How much value/items can be claimed in exchange for the voucher 209 o Restrictions applied to the voucher 210 - Participants (VTS Provider, Issuer, Holder, and Collector) 211 - Objects (merchandise) to be claimed 212 - Time when valid (validity period) 213 - Others 215 The Voucher Component also provides common properties useful for 216 displaying and manipulating the contents of wallet systems. It 217 includes the title and description of each voucher. 219 The Voucher Component contains the Title Component, Description 220 Component, Provider Component, Issuer Component, Holder Component, 221 Collector Component, Value Component, Merchandise Component, 222 ValidPeriod Component, and Condition Component as follows: 224 Title Component 226 Provides the title of the voucher. This is mainly for listing 227 the entities stored in a wallet system. 229 Description Component 231 Provides a short description of the voucher. This is mainly for 232 listing the entities stored in a wallet system. 234 Provider Component 236 Provides restrictions on which VTS Provider (or VTS plug-in) can 237 be used for trading the voucher. 239 Issuer Component 241 Provides restrictions on the Issuer of the voucher. 243 Holder Component 245 Provides restrictions on the Holder of the voucher. 247 Collector Component 248 Provides restrictions on the Collector of the voucher. 250 Value Component 252 Provides the value of each voucher. There are two types of 253 values, i.e., fixed and ratio values. For a fixed value, the 254 currency and the figure is specified. For a ratio value, the 255 discount ratio of the corresponding merchandize is specified. 257 The Value Component also indicates the number of vouchers to be 258 redeemed for claiming the merchandise or monetary value specified 259 in Merchandise Component or Value Component. If "n"(>0) is 260 specified, the merchandize or monetary value can be claimed in 261 exchange for "n sheets of" vouchers. If "0" is specified, it 262 can be used repeatedly. 264 Merchandise Component 266 Provides restrictions on the object to be claimed. 267 Domain-specific meaning of the voucher, e.g., reference number of 268 the merchandize or seat number for an event ticket, is specified 269 to identify the merchandize rendered when the voucher is 270 redeemed. 272 ValidPeriod Component 274 Provides restrictions on the validity period of the voucher, 275 i.e., start date and end date. 277 Condition Component 279 Provides any other applicable restrictions. This is intended to 280 cover contracts between the issuer and holder of the 281 voucher in natural language form. 283 Using the above Components, semantics for diverse types of vouchers 284 can be defined as shown in Table 1. 286 +----------------+--------------------------------+---------------+ 287 | | Value | Restrictions | 288 | +-----+---------------+----------+---------------+ 289 | Examples |Ratio| Fixed |Number | Merchandise | 290 | | +------+--------+Needed for| | 291 | | |Amount|Currency|redemption| | 292 +----------------+-----+------+--------+----------+---------------+ 293 |Gift certificate| | 25 | USD | 1 |(Not specified)| 294 |Loyalty point | | 1 | AUD | 10 |(Not specified)| 295 |Member card | 20%| | | 0 |(Not specified)| 296 |Coupon | 30%| | | 1 |Beef 500g | 297 |Event ticket | 100%| | | 1 |Hall A, S ,K23 | 298 |Exchange ticket | 100%| | | 1 |ISBN:0071355014| 299 +----------------+-----+------+--------+----------+---------------+ 300 Table 1. Examples of vouchers and their properties 302 5. Syntax Overview and Examples 304 This section provides an overview and examples of Voucher 305 Component. The formal syntax and semantics are found in Sections 6 306 and 7. 308 Voucher Components are represented by the <Voucher> element which 309 has the following structure (where "?" denotes zero or one 310 occurrence): 312 <Voucher> 313 (Title) 314 (Description)? 315 (Provider) 316 (Issuer)? 317 (Holder)? 318 (Collector)? 319 (Value) 320 (Merchandise)? 321 (ValidPeriod)? 322 (Conditions)? 323 </Voucher> 325 An example of a Voucher Component is described below. This is an 326 example of a five dollar discount coupon for specific merchandize, 327 a book with ISBN number 0071355014. The coupon is valid from April 328 1st in 2001 to March 31st in 2002. To claim this offer, one voucher 329 must be spent. 331 <?xml version="1.0"?> 332 <Voucher xmlns="urn:ietf:params:xml:schema:vts-lang" 333 xmlns:vts="http://www.example.com/vts"> 334 <Title>IOTP Book Coupon 335 $5 off IOTP Book 336 337 VE2.31 338 339 340 341 1DA8DFCF95521014BBB7171B95545E8D61AE803F 342 343 344 345 346 347 348 349 351 352 353 354 The value of this coupon is subject to tax. 355 356 358 6. Syntax and Semantics 360 The general structure of an XML voucher is described in Component 361 Structure (section 4). This section details the Voucher Component 362 features. Features described in this section MUST be implemented 363 unless otherwise indicated. The syntax is defined via 364 [XML-Schema-1] [XML-Schema-2]. For clarity, unqualified elements in 365 schema definitions are in the XML schema namespace: 367 xmlns="http://www.w3.org/2001/XMLSchema" 369 References to XML Voucher schema defined herein use the prefix 370 "gvl" and are in the namespace: 372 xmlns:gvl="urn:ietf:params:xml:schema:vts-lang" 374 This namespace URI for elements defined by this document is a URN 375 [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] 376 and extended by [XML-Registry]. 378 This namespace is also used for unqualified elements in voucher 379 examples. 381 6.1 383 The element contains , <Provider>, and <Value> 384 elements and optionally contains <Description>, <Issuer>, <Holder>, 385 <Collector>, <ValidPeriod>, and <Condition> elements. These 386 sub-elements are defined in the following sections. 388 The <Voucher> element is defined by the following schema: 390 <element name="Voucher" type="gvl:VoucherType"/> 391 <complexType name="VoucherType"> 392 <sequence> 393 <element ref="gvl:Title"/> 394 <element ref="gvl:Description" minOccurs="0"/> 395 <element ref="gvl:Provider"/> 396 <element ref="gvl:Issuer" minOccurs="0"/> 397 <element ref="gvl:Holder" minOccurs="0"/> 398 <element ref="gvl:Collector" minOccurs="0"/> 399 <element ref="gvl:Value"/> 400 <element ref="gvl:Merchandise" minOccurs="0"/> 401 <element ref="gvl:ValidPeriod" minOccurs="0"/> 402 <element ref="gvl:Conditions" minOccurs="0"/> 403 </sequence> 404 </complexType> 406 6.2 <Title> 408 The <Title> element contains a simpletext title of the voucher. 409 This is mainly for listing the entities stored in a wallet system. 411 The <Title> element has no attribute. 413 The <Title> element is defined by the following schema: 415 <element name="Title" type="string"/> 417 6.3 <Description> 419 The <Description> element contains a simpletext description of the 420 voucher. This is mainly for listing the entities stored in a 421 wallet system. 423 The <Description> element has no attribute. 425 The <Description> element is defined by the following schema: 427 <element name="Description" type="string"/> 429 6.4 <Provider> 431 The <Provider> element may contain any elements that is used to 432 specify or restrict the VTS Provider of the voucher. The 433 sub-elements contained in this element depend on the implementation 434 of the VTS. 436 An implementation of a wallet system may use this information to 437 identify and/or authenticate the VTS Provider when the VTS plug-in is 438 registered (See Section 7 of [VTS-API]). These 439 implementation-specific elements of the VTS can be extended using 440 [XML-ns]. An example of such schema definition is described in 441 Section 8. 443 The <Provider> element has a string-type "name" attribute that is 444 used to specify the name of the VTS Provider. 446 The <Provider> element is defined by the following schema: 448 <element name="Provider" type="gvl:RoleType"/> 449 <complexType name="RoleType" mixed="true"> 450 <sequence> 451 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 452 </sequence> 453 <attribute name="name" type="string"/> 454 </complexType> 456 6.5 <Issuer> 457 The <Issuer> element may contain any element that is used to specify 458 or restrict the Issuer of the voucher. 460 The Issuer of the voucher is generally managed by the VTS [VTS-API]. 461 There is no need to specify the Issuer of the voucher using this 462 element if there are no restrictions on the Issuer. 463 An implementation of a VTS may use this element to describe the 464 authentication data and/or qualification information of the 465 Issuer. This implementation-specific information can be extended as 466 sub-elements using [XML-ns]. An example of such schema definition is 467 described in Section 8. 469 The <Issuer> element has a string-type "name" attribute that is used 470 to specify the name of the Issuer. 472 The <Issuer> element is defined by the following schema: 474 <element name="Issuer" type="gvl:RoleType"/> 475 The <RoleType> element type is defined in Section 6.4. 477 If the <Issuer> element is omitted, it MUST be interpreted that there 478 are no restrictions on the Issuer. 480 6.6 <Holder> 482 The <Holder> element may contain any elements that is used to specify 483 or restrict the Holder of the voucher. 485 The Holder of the voucher is generally managed by the VTS [VTS-API]. 486 There is no need to specify the Holder of the voucher using this 487 element if there are no restrictions on the Holder. 488 An implementation of a VTS may use this element to describe the 489 authentication data and/or qualification information of the 490 Holder. This implementation-specific information can be extended as 491 sub-elements using [XML-ns]. 493 The <Holder> element has a string-type "name" attribute that is used 494 to specify the name of the Holder. 496 The <Holder> element is defined by the following schema: 498 <element name="Holder" type="gvl:RoleType"/> 499 The <RoleType> element type is defined in Section 6.4. 501 If the <Holder> element is omitted, it MUST be interpreted that there 502 are no restrictions on the Holder. 504 6.7 <Collector> 506 The <Collector> element may contain any elements that is used to 507 specify or restrict the Collector of the voucher. 509 There is no need to specify the Collector of the voucher using this 510 element if there are no restrictions on the Collector. 511 An implementation of a VTS may use this element to describe the 512 authentication data and/or qualification information of the 513 Collector. This implementation-specific information can be extended 514 as sub-elements using [XML-ns]. 516 The <Collector> element has a string-type "name" attribute that is 517 used to specify the name of the Collector. 519 The <Collector> element is defined by the following schema: 521 <element name="Collector" type="gvl:RoleType"/> 522 The <RoleType> element type is defined in Section 6.4. 524 If the <Collector> element is omitted, it MUST be interpreted that 525 there are no restrictions on the Collector. 527 6.8 <Value> 529 The <Value> element optionally contains a <Fixed> or a <Ratio> 530 element but not both. These sub-elements are defined in the 531 following sections. 533 The <Value> element has a "type" attribute that is used to specify 534 the value process type. This attribute is provided to calculate the 535 amount paid when the vouchers are redeemed at Merchant site, etc. 537 The following identifiers are defined for the "type" attribute. 539 Exchange: Items specified in the <Merchandise> element can be 540 claimed in exchange for the voucher. If this type is selected, 541 neither <Ratio> nor <Fixed> element MUST be specified. Note that 542 this value process type has the same meaning as: 543 <Value type="discount"><Ratio percentage="100"/></Value> 545 Discount: Items specified in the <Merchandise> element can be 546 purchased at the discount price calculated by the <Ratio> or 547 <Fixed> element. 549 Monetary: Items specified in the <Merchandise> element can be 550 purchased using the value of the voucher. (Note: if the 551 <Merchandise> element is not specified, the voucher can be used 552 for any purchase.) If this type is selected, the <Fixed> element 553 MUST be specified. 555 The <Value> element also has a "spend" attribute that is used to 556 specify the number of vouchers to be redeemed for claiming the 557 goods, services, or monetary value specified. For example, if "n" 558 (>0) is specified, goods etc. can be claimed in exchange for "n 559 sheets of" vouchers. (Note: Multiple vouchers for the same Voucher 560 Component must exist in this case.) If "0" is specified, it can be 561 used repeatedly. 563 If the "spend" attribute is omitted or the whole element is omitted, 564 it MUST be interpreted that "1" is specified for the "spend" 565 attribute. 567 The <Value> element is defined by the following schema: 569 <element name="Value" type="gvl:ValueType"/> 570 <complexType name="ValueType"> 571 <sequence minOccurs="0"> 572 <choice> 573 <element name="Ratio" type="gvl:RatioValueType"/> 574 <element name="Fixed" type="gvl:FixedValueType"/> 575 </choice> 576 </sequence> 577 <attribute name="type" type="gvl:ValueProcessType" 578 use="required"/> 579 <attribute name="spend" type="nonNegativeInteger" 580 default="1"/> 581 </complexType> 583 The <ValueProcessType> element type is defined by the following 584 schema: 586 <simpleType name="ValueProcessType"> 587 <restriction base="string"> 588 <enumeration value="exchange"/> 589 <enumeration value="discount"/> 590 <enumeration value="monetary"/> 591 </restriction> 592 </simpleType> 594 6.8.1 <Ratio> 596 The <Ratio> element does not contain any contents. 598 The <Ratio> element has a "percentage" attribute that is used to 599 specify the discount ratio of the price of the corresponding 600 merchandize in percentage. 602 The <RatioValueType> element type is defined by the schema: 604 <complexType name="RatioValueType"> 605 <attribute name="percentage" use="required"> 606 <simpleType> 607 <restriction base="float"> 608 <maxInclusive value="100"/> 609 </restriction> 610 </simpleType> 611 </attribute> 612 </complexType> 614 6.8.2 <Fixed> 615 The <Fixed> element does not contain any contents. 617 The <Fixed> element has "currency" and "amount" attributes 618 and optionally a "decimalPower" attribute as follows: 620 Currency: Provides the unit of the monetary value in the three 621 letter ISO currency code [ISO4217]. For example, for US dollars 622 it is "USD". 624 Amount: Provides the amount of the monetary value per voucher. 626 DecimalPower: Provides the number of decimal digits from the 627 decimal point applied to the base for the "amount" attribute 628 above. If the "decimalPower" attribute is omitted, it MUST be 629 interpreted that "0" is specified for the "decimalPower" 630 attribute. 632 For example, with a dollar currency denominated in cents, "1" is 633 specifed for the "amount" attribute, and "-2" is specified for the 634 "decimalPower" attribute. Alternately, "0.01" is specified for 635 the "amount" attribute and the "decimalPower" attribute is omitted. 637 The <FixedValueType> type is defined by the following definition: 639 <complexType name="FixedValueType"> 640 <attribute name="currency" type="string" use="required"/> 641 <attribute name="amount" type="float" use="required"/> 642 <attribute name="decimalPower" type="short" default="0"/> 643 </complexType> 645 6.9 <Merchandise> 647 The <Merchandise> element may contain any elements used to specify or 648 restrict the goods or services rendered when the voucher is redeemed. 649 The sub-elements contained in this element are depending on the 650 application of the voucher and are left to the other domain-specific 651 specifications. Domain-specific elements can be extended as 652 sub-elements using [XML-ns]. 654 The <Merchandise> element does not have any attribute. 656 The <Merchandise> element is defined by the following schema: 658 <element name="Merchandise" type="gvl:MerchandiseType"/> 659 <complexType name="MerchandiseType" mixed="true"> 660 <sequence> 661 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 662 </sequence> 663 </complexType> 665 If the <Merchandise> element is omitted, it will be generally 666 interpreted that there is no restriction on the merchandise when 667 using the voucher. 669 6.10 <ValidPeriod> 671 The <VaridPeriod> element does not contain any contents. 673 The <ValidPeriod> element has dateTime-type "start" and "end" 674 attributes that are used to place limits on the validity of the 675 voucher. 677 The <ValidPeriod> element is defined by the following schema: 679 <element name="ValidPeriod" type="gvl:ValidPeriodType"/> 680 <complexType name="ValidPeriodType"> 681 <attribute name="start" type="dateTime"/> 682 <attribute name="end" type="dateTime"/> 683 </complexType> 685 If the "start" attribute is omitted, it MUST be interpreted that 686 the voucher is valid on any date up to the date (inclusive) 687 specified by the end attribute. If the "end" attribute is omitted, 688 it MUST be interpreted that the voucher is valid from the start 689 attribute with no expiry. If neither attribute is specified or the 690 whole element is omitted, it MUST be interpreted that the voucher 691 is valid at any time. 693 6.10 <Conditions> 695 The <Conditions> element may contain any element used to specify 696 any other restrictions or conditions applied that limit the use of 697 the voucher. The sub-elements contained in this element are 698 depending on the application of the voucher and are left to the 699 other domain-specific specifications. Domain-specific elements can 700 be extended as sub-elements using [XML-ns]. 702 The <Conditions> element does not have any attribute. 704 The <Conditions> element is defined by the following schema: 706 <element name="Conditions" type="gvl:ConditionsType"/> 707 <complexType name="ConditionsType" mixed="true"> 708 <sequence> 709 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 710 </sequence> 711 </complexType> 713 If the <Conditions> element is omitted, it will be generally 714 interpreted that there are no other restrictions or conditions on 715 using the voucher. 717 7. IANA Considerations 719 This document calls for IANA to register a new XML schema with the 720 URN. The registation form [XML-Registry] for this is below: 722 URI 723 urn:ietf:params:xml:schema:vts-lang 725 Registrant Contact 726 IETF, trade working group, <ietf-trade@lists.elistx.com> 727 Ko Fujimura, <fujimura@isl.ntt.co.jp> 729 XML 730 BEGIN 731 <?xml version="1.0"?> 733 <schema 734 targetNamespace="urn:ietf:params:xml:schema:vts-lang" 735 xmlns:gvl="urn:ietf:params:xml:schema:vts-lang" 736 xmlns="http://www.w3.org/2001/XMLSchema" 737 elementFormDefault="qualified"> 739 <element name="Voucher" type="gvl:VoucherType"/> 740 <complexType name="VoucherType"> 741 <sequence> 742 <element ref="gvl:Title"/> 743 <element ref="gvl:Description" minOccurs="0"/> 744 <element ref="gvl:Provider"/> 745 <element ref="gvl:Issuer" minOccurs="0"/> 746 <element ref="gvl:Holder" minOccurs="0"/> 747 <element ref="gvl:Collector" minOccurs="0"/> 748 <element ref="gvl:Value"/> 749 <element ref="gvl:Merchandise" minOccurs="0"/> 750 <element ref="gvl:ValidPeriod" minOccurs="0"/> 751 <element ref="gvl:Conditions" minOccurs="0"/> 752 </sequence> 753 </complexType> 755 <element name="Title" type="string"/> 757 <element name="Description" type="string"/> 759 <element name="Provider" type="gvl:RoleType"/> 760 <element name="Issuer" type="gvl:RoleType"/> 761 <element name="Holder" type="gvl:RoleType"/> 762 <element name="Collector" type="gvl:RoleType"/> 763 <complexType name="RoleType" mixed="true"> 764 <sequence> 765 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 766 </sequence> 767 <attribute name="name" type="string"/> 768 </complexType> 770 <element name="Value" type="gvl:ValueType"/> 771 <complexType name="ValueType"> 772 <sequence minOccurs="0"> 773 <choice> 774 <element name="Ratio" type="gvl:RatioValueType"/> 775 <element name="Fixed" type="gvl:FixedValueType"/> 776 </choice> 777 </sequence> 778 <attribute name="type" type="gvl:ValueProcessType" 779 use="required"/> 780 <attribute name="spend" type="nonNegativeInteger" 781 default="1"/> 782 </complexType> 784 <simpleType name="ValueProcessType"> 785 <restriction base="string"> 786 <enumeration value="exchange"/> 787 <enumeration value="discount"/> 788 <enumeration value="monetary"/> 789 </restriction> 790 </simpleType> 792 <complexType name="RatioValueType"> 793 <attribute name="percentage" use="required"> 794 <simpleType> 795 <restriction base="float"> 796 <maxInclusive value="100"/> 797 </restriction> 798 </simpleType> 799 </attribute> 800 </complexType> 802 <complexType name="FixedValueType"> 803 <attribute name="currency" type="string" use="required"/> 804 <attribute name="amount" type="float" use="required"/> 805 <attribute name="decimalPower" type="short" default="0"/> 806 </complexType> 808 <element name="Merchandise" type="gvl:MerchandiseType"/> 809 <complexType name="MerchandiseType" mixed="true"> 810 <sequence> 811 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 812 </sequence> 813 </complexType> 815 <element name="ValidPeriod" type="gvl:ValidPeriodType"/> 816 <complexType name="ValidPeriodType"> 817 <attribute name="start" type="dateTime"/> 818 <attribute name="end" type="dateTime"/> 819 </complexType> 821 <element name="Conditions" type="gvl:ConditionsType"/> 822 <complexType name="ConditionsType" mixed="true"> 823 <sequence> 824 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 825 </sequence> 826 </complexType> 828 </schema> 829 END 831 8. VTS Schema Example 833 An example of the schema definition for a VTS implementation is 834 described below: 836 <?xml version="1.0"?> 838 <schema 839 targetNamespace="http://www.example.com/vts" 840 xmlns:vts="http://www.example.com/vts" 841 xmlns="http://www.w3.org/2001/XMLSchema" 842 elementFormDefault="qualified"> 844 <element name="Version" type="string"/> 845 <element name="KeyInfo" type="hexBinary"/> 846 </schema> 848 Using this schema definition, the <vts:Version> can be used for 849 specifying the VTS version number and the <vts:KeyInfo> element can 850 be used for specifying the Issuer in the Voucher Component as shown 851 in Section 5. 853 9. Security Considerations 855 Security issues for delivering Voucher Components are discussed in 856 Section 3. 858 10. References 860 [ECML] J. W. Parsons and D. Eastlake, "Electronic Commerce Modeling 861 Language (ECML) Version 2 Specification", 862 draft-ietf-trade-ecml2-spec-03.txt, April 2002. 864 [GVT] K. Fujimura, "Requirements and Design for Voucher Trading 865 System (VTS)", draft-ietf-trade-drt-requirements-03.txt, January 866 2002. 868 [IPSEC] R. Thayer, N. Doraswamy, and R. Glenn, "IP Security Document 869 Roadmap", RFC2411, November 1998 871 [ISO4217] "Codes for the representation of currencies and funds", 872 ISO 4217, 1995. 874 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 875 Requirement Levels", BCP 14, RFC 2119, March 1997. 877 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, 878 January 1999. 880 [URN] R. Moats, "URN Syntax", RFC2141, May 1997. 882 [URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents", 883 RFC2648, August 1999. 885 [VTS-API] M. Terada and K. Fujimura, "Voucher Trading System 886 Application Programming Interface (VTS-API)", 887 draft-ietf-trade-voucher-vtsapi-01.txt, January 2002. 889 [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A 890 W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000. 892 [XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature 893 Syntax and Processing", RFC3275, March 2002. 895 [XML-ns] "Namespaces in XML", A W3C Recommendation, 896 <http://www.w3.org/TR/REC-xml-names>, January 1999. 898 [XML-Registry] M. Mealing, "The IETF XML Registry", 899 draft-mealling-iana-xmlns-registry-03, November 2001. 901 [XML-Schema-1] H. Thompson, D. Beech, M. Maloney, and 902 N. Mendelsohn, "XML Schema Part 1: Structures W3C Recommendation.", 903 <http://www.w3.org/TR/xmlschema-1/>, May 2001. 905 [XML-Schema-2] P. Biron and A Malhotra, "XML Schema Part 2: 906 Datatypes W3C Recommendation.", 907 <http://www.w3.org/TR/xmlschema-2/>, May 2001. 909 11. Author's Address 911 Ko Fujimura and Masayuki Terada 912 NTT Corporation 913 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 914 Phone: +81-(0)468-59-3814 915 Fax: +81-(0)468-59-2241 916 Email: fujimura@isl.ntt.co.jp, terada@isl.ntt.co.jp 918 Full Copyright Statement 920 Copyright (C) The Internet Society (2002). All Rights Reserved. 922 This document and translations of it may be copied and furnished to 923 others, and derivative works that comment on or otherwise explain it 924 or assist in its implementation may be prepared, copied, published 925 and distributed, in whole or in part, without restriction of any 926 kind, provided that the above copyright notice and this paragraph are 927 included on all such copies and derivative works. However, this 928 document itself may not be modified in any way, such as by removing 929 the copyright notice or references to the Internet Society or other 930 Internet organizations, except as needed for the purpose of 931 developing Internet standards in which case the procedures for 932 copyrights defined in the Internet Standards process must be 933 followed, or as required to translate it into languages other than 934 English. 936 The limited permissions granted above are perpetual and will not be 937 revoked by the Internet Society or its successors or assigns. 939 This document and the information contained herein is provided on an 940 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 941 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 942 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 943 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 944 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.