idnits 2.17.1 draft-ietf-trade-voucher-lang-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 162 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.) -- The document date (February 2004) is 7377 days in the past. Is this intentional? 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 123, but not defined == Unused Reference: 'RFC2119' is defined on line 882, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' ** Obsolete normative reference: RFC 2141 (ref. 'URN') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. 'URN-NS-IETF') -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-ns' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-Schema-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-Schema-2' -- Obsolete informational reference (is this intentional?): RFC 2411 (ref. 'IPSEC') (Obsoleted by RFC 6071) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Trade Working Group February 2004 3 INTERNET-DRAFT Ko Fujimura 4 NTT 5 Masayuki Terada 6 NTT DoCoMo 7 Expires: August 2004 9 XML Voucher: Generic Voucher Language 10 12 Status of This Document 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Distribution of this document is unlimited. Please send comments to 34 the TRADE working group at , which may 35 be joined by sending a message with subject "subscribe" to . 38 Discussions of the TRADE working group are archived at 39 http://lists.elistx.com/archives/ietf-trade. 41 Abstract 43 This document specifies rules for defining voucher properties in XML 44 syntax. A voucher is a logical entity that represents a right to 45 claim goods or services. A voucher can be used to transfer a 46 wide-range of electronic-values, including coupons, tickets, loyalty 47 points, and gift certificates, which are often necessary to process 48 in the course of payment and/or delivery transactions. 50 Copyright (C) The Internet Society (2004). All Rights Reserved. 52 Acknowledgements 54 The following persons, in alphabetic order, contributed substantially 55 to the material herein: 57 Donald Eastlake 3rd 58 Ian Grigg 59 Renato Iannella 60 Yoshiaki Nakajima 62 Table of Contents 64 Status of this Memo ...............................................1 65 Abstract ..........................................................1 66 Acknowledgments ...................................................2 67 Table of Contents .................................................2 69 1. Introduction ...................................................3 70 2. Processing Model ...............................................3 71 3. Trust Model ....................................................4 72 4. Component Structure ............................................5 73 5. Syntax Overview and Examples ...................................7 74 6. Syntax and Semantics ...........................................8 75 6.1 ..................................................8 76 6.2 ....................................................9 77 6.3 <Description> ..............................................9 78 6.4 <Provider> .................................................9 79 6.5 <Issuer> ...................................................9 80 6.6 <Holder> ..................................................10 81 6.7 <Collector> ...............................................10 82 6.8 <Value> ...................................................11 83 6.8.1 <Ratio> .................................................12 84 6.8.2 <Fixed> .................................................12 85 6.9 <Merchandise> .............................................13 86 6.10 <ValidPeriod> ............................................14 87 6.11 <Conditions> .............................................14 88 7. IANA Considerations ...........................................14 89 8. VTS Schema Example ............................................17 90 9. Security Considerations .......................................17 91 10. Normative References ..........................................17 92 11. Informational References ......................................18 93 12. Author's Address ..............................................18 95 Full Copyright Statement ..........................................19 97 1. Introduction 99 This document, XML Voucher, specifies rules for defining voucher 100 properties in XML syntax. The motivation and background of the 101 specification are described in [VTS]. 103 A voucher is a logical entity that represents a certain right and 104 is logically managed by the Voucher Trading System (VTS). A voucher 105 is generated by the issuer, traded among users, and finally 106 collected by the collector using VTS. 108 This document defines the syntax and semantics of Voucher 109 Component, which defines voucher meaning and processing rules in 110 XML syntax [XML]. A Voucher Component define the properties that 111 must be satisfied to allow the voucher to be processed by VTS or 112 other trading systems, e.g., wallet or merchant system. VTS 113 definitions and models are also defined in [VTS]. 115 Note: This document uses "voucher" as an "instance of voucher" 116 whose meaning is defined by Voucher Component. In other words, 117 multiple vouchers can be issued and managed by the VTS using the 118 same Voucher Component. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 122 this document are to be interpreted as described in [RFC 2119] 124 2. Processing Model 126 There are several ways of implementing VTS and technologies are 127 continually changing. For discount coupons or event tickets, for 128 example, the smart-card-based offline VTS is often preferred, 129 whereas for bonds or securities, the centralized online VTS is 130 preferred. It is impractical to define standard protocols for 131 issuing, transferring, or redeeming vouchers at this moment. 133 To provide implementation flexibility, this document assumes a 134 modular wallet architecture that allows multiple VTS to be added as 135 plug-ins. In this architecture, instead of specifying a standard 136 voucher transfer protocol, two specifications, i.e., Voucher 137 Component and VTS-API specifications, are standardized (Figure 1). 139 After sender and receiver agree on what vouchers are to be traded 140 and which VTS is to be used, the issuing system or wallet system 141 requests the corresponding VTS plug-in to permit the issue, 142 transfer, or redeem transactions to be performed via the VTS 143 API. The VTS then rewrites the ownership of the vouchers using the 144 VTS-specific protocol. Finally, a completion event is sent to the 145 wallet systems or issuing/collecting systems. 147 This document describes the Voucher Component specification. The 148 VTS-API specification is defined in [VTS-API]. 150 Sender wallet/Issuing system Receiver wallet/Collecting system 151 +---------------------------+ +---------------------------+ 152 | | | | 153 | | Voucher Component | | 154 | | (Specifies VTS Provider and Promise) | | 155 | |-------------------------------------------------------->| | 156 | | | | | | 157 | | Intention to receive and payment (option) | | 158 | |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | | 159 | | | | | | 160 | | | | | | 161 | | Issue/transfer/ VTS | | VTS Register | | 162 | | redeem request plug-in | plug-in Listener(*1)| | 163 | |------------------>| | | |<------------------| | 164 | | (VTS-API) |<- - - - - - - ->| (VTS-API) | | 165 | | | VTS-specific | | | 166 | | | protocol if VTS | | | 167 | | | is distributed | | | 168 | | Result |<- - - - - - - ->| Notify(*2) | | 169 | |<------------------| | | |------------------>| | 170 +---------------------------+ +---------------------------+ 171 (*1) Registration is optional. Note also that the VTS plug-ins are 172 usually pre-registered when the wallet or collecting system 173 is started. 174 (*2) If a listener is registered. 176 Figure 1. Wallet architecture with VTS plug-ins 178 3. Trust Model 180 A voucher is trusted if the Issuer and VTS Provider are trusted, 181 since the Issuer is responsible for the contents of the voucher and 182 the VTS Provider is responsible for preventing ownership from being 183 assigned to multiple users. 185 The trust level required for Issuer and VTS Provider depends on the 186 type (or Promise) of the voucher. To provide the information needed 187 for verification, the conditions of Issuer and VTS Provider are 188 specified in the Voucher Component, and given as input to the 189 verifier, e.g., wallet system or other software. The trust of a 190 voucher is thus verified through the Voucher Component. This model 191 enables trading partners to verify their trust in the voucher 192 regardless of their trust in the partners. 194 This document assumes that the Voucher Component is the root of 195 trust. If a malicious user could alter the Voucher Component, a 196 forged voucher, could be verified as valid. 198 The Voucher Component is usually delivered from the trusted VTS 199 Provider, Issuer or trusted third party using a secure 200 communication channel, such as [XMLDSIG], [TLS], or [IPSEC]. 201 Delivery of the Voucher Component is beyond the scope of this 202 document. 204 Note: The Voucher Component does not have to be sent from the 205 sender of the voucher. Note also that a set of trusted Voucher 206 Components can be downloaded before conducting a transaction. 208 4. Component Structure 210 The Voucher Component provides the information needed to identify 211 the monetary value or merchandize rendered when the voucher is 212 redeemed. It includes: 214 o How much value/items can be claimed in exchange for the voucher 216 o Restrictions applied to the voucher 217 - Participants (VTS Provider, Issuer, Holder, and Collector) 218 - Objects (merchandise) to be claimed 219 - Time when valid (validity period) 220 - Others 222 The Voucher Component also provides common properties useful for 223 displaying and manipulating the contents of wallet systems. It 224 includes the title and description of each voucher. 226 The Voucher Component contains the Title Component, Description 227 Component, Provider Component, Issuer Component, Holder Component, 228 Collector Component, Value Component, Merchandise Component, 229 ValidPeriod Component, and Condition Component as follows: 231 Title Component 233 Provides the title of the voucher. This is mainly for listing 234 the entities stored in a wallet system. 236 Description Component 238 Provides a short description of the voucher. This is mainly for 239 listing the entities stored in a wallet system. 241 Provider Component 243 Provides restrictions on which VTS Provider (or VTS plug-in) can 244 be used for trading the voucher. 246 Issuer Component 248 Provides restrictions on the Issuer of the voucher. 250 Holder Component 252 Provides restrictions on the Holder of the voucher. 254 Collector Component 255 Provides restrictions on the Collector of the voucher. 257 Value Component 259 Provides the value of each voucher. There are two types of 260 values, i.e., fixed and ratio values. For a fixed value, the 261 currency and the figure is specified. For a ratio value, the 262 discount ratio of the corresponding merchandize is specified. 264 The Value Component also indicates the number of vouchers to be 265 redeemed for claiming the merchandise or monetary value specified 266 in Merchandise Component or Value Component. If "n"(>0) is 267 specified, the merchandize or monetary value can be claimed in 268 exchange for "n sheets of" vouchers. If "0" is specified, it 269 can be used repeatedly. 271 Merchandise Component 273 Provides restrictions on the object to be claimed. 274 Domain-specific meaning of the voucher, e.g., reference number of 275 the merchandize or seat number for an event ticket, is specified 276 to identify the merchandize rendered when the voucher is 277 redeemed. 279 ValidPeriod Component 281 Provides restrictions on the validity period of the voucher, 282 i.e., start date and end date. 284 Condition Component 286 Provides any other applicable restrictions. This is intended to 287 cover contracts between the issuer and holder of the 288 voucher in natural language form. 290 Using the above Components, semantics for diverse types of vouchers 291 can be defined as shown in Table 1. 293 +----------------+--------------------------------+---------------+ 294 | | Value | Restrictions | 295 | +-----+---------------+----------+---------------+ 296 | Examples |Ratio| Fixed |Number | Merchandise | 297 | | +------+--------+Needed for| | 298 | | |Amount|Currency|redemption| | 299 +----------------+-----+------+--------+----------+---------------+ 300 |Gift certificate| | 25 | USD | 1 |(Not specified)| 301 |Loyalty point | | 1 | AUD | 10 |(Not specified)| 302 |Member card | 20%| | | 0 |(Not specified)| 303 |Coupon | 30%| | | 1 |Beef 500g | 304 |Event ticket | 100%| | | 1 |Hall A, S ,K23 | 305 |Exchange ticket | 100%| | | 1 |ISBN:0071355014| 306 +----------------+-----+------+--------+----------+---------------+ 307 Table 1. Examples of vouchers and their properties 309 5. Syntax Overview and Examples 311 This section provides an overview and examples of Voucher 312 Component. The formal syntax and semantics are found in Sections 6 313 and 7. 315 Voucher Components are represented by the <Voucher> element which 316 has the following structure (where "?" denotes zero or one 317 occurrence): 319 <Voucher> 320 (Title) 321 (Description)? 322 (Provider) 323 (Issuer)? 324 (Holder)? 325 (Collector)? 326 (Value) 327 (Merchandise)? 328 (ValidPeriod)? 329 (Conditions)? 330 </Voucher> 332 An example of a Voucher Component is described below. This is an 333 example of a five dollar discount coupon for specific merchandize, 334 a book with ISBN number 0071355014. The coupon is valid from April 335 1st in 2001 to March 31st in 2002. To claim this offer, one voucher 336 must be spent. 338 <?xml version="1.0"?> 339 <Voucher xmlns="urn:ietf:params:xml:ns:vts-lang" 340 xmlns:vts="http://www.example.com/vts"> 341 <Title>IOTP Book Coupon 342 $5 off IOTP Book 343 344 VE2.31 345 346 347 348 1DA8DFCF95521014BBB7171B95545E8D61AE803F 349 350 351 352 353 354 355 356 358 359 360 361 The value of this coupon is subject to tax. 362 363 365 6. Syntax and Semantics 367 The general structure of an XML voucher is described in Component 368 Structure (section 4). This section details the Voucher Component 369 features. Features described in this section MUST be implemented 370 unless otherwise indicated. The syntax is defined via 371 [XML-Schema-1] [XML-Schema-2]. For clarity, unqualified elements in 372 schema definitions are in the XML schema namespace: 374 xmlns="http://www.w3.org/2001/XMLSchema" 376 References to XML Voucher schema defined herein use the prefix 377 "gvl" and are in the namespace: 379 xmlns:gvl="urn:ietf:params:xml:ns:vts-lang" 381 This namespace URI for elements defined by this document is a URN 382 [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] 383 and extended by [XML-Registry]. 385 This namespace is also used for unqualified elements in voucher 386 examples. 388 6.1 390 The element contains , <Provider>, and <Value> 391 elements and optionally contains <Description>, <Issuer>, <Holder>, 392 <Collector>, <ValidPeriod>, and <Condition> elements. These 393 sub-elements are defined in the following sections. 395 The <Voucher> element is defined by the following schema: 397 <element name="Voucher" type="gvl:VoucherType"/> 398 <complexType name="VoucherType"> 399 <sequence> 400 <element ref="gvl:Title"/> 401 <element ref="gvl:Description" minOccurs="0"/> 402 <element ref="gvl:Provider"/> 403 <element ref="gvl:Issuer" minOccurs="0"/> 404 <element ref="gvl:Holder" minOccurs="0"/> 405 <element ref="gvl:Collector" minOccurs="0"/> 406 <element ref="gvl:Value"/> 407 <element ref="gvl:Merchandise" minOccurs="0"/> 408 <element ref="gvl:ValidPeriod" minOccurs="0"/> 409 <element ref="gvl:Conditions" minOccurs="0"/> 410 </sequence> 411 </complexType> 413 6.2 <Title> 415 The <Title> element contains a simpletext title of the voucher. 416 This is mainly for listing the entities stored in a wallet system. 418 The <Title> element has no attribute. 420 The <Title> element is defined by the following schema: 422 <element name="Title" type="string"/> 424 6.3 <Description> 426 The <Description> element contains a simpletext description of the 427 voucher. This is mainly for listing the entities stored in a 428 wallet system. 430 The <Description> element has no attribute. 432 The <Description> element is defined by the following schema: 434 <element name="Description" type="string"/> 436 6.4 <Provider> 438 The <Provider> element may contain any elements that is used to 439 specify or restrict the VTS Provider of the voucher. The 440 sub-elements contained in this element depend on the implementation 441 of the VTS. 443 An implementation of a wallet system may use this information to 444 identify and/or authenticate the VTS Provider when the VTS plug-in is 445 registered (See Section 7 of [VTS-API]). These 446 implementation-specific elements of the VTS can be extended using 447 [XML-ns]. An example of such schema definition is described in 448 Section 8. 450 The <Provider> element has a string-type "name" attribute that is 451 used to specify the name of the VTS Provider. 453 The <Provider> element is defined by the following schema: 455 <element name="Provider" type="gvl:RoleType"/> 456 <complexType name="RoleType" mixed="true"> 457 <sequence> 458 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 459 </sequence> 460 <attribute name="name" type="string"/> 461 </complexType> 463 6.5 <Issuer> 464 The <Issuer> element may contain any element that is used to specify 465 or restrict the Issuer of the voucher. 467 The Issuer of the voucher is generally managed by the VTS [VTS-API]. 468 There is no need to specify the Issuer of the voucher using this 469 element if there are no restrictions on the Issuer. 470 An implementation of a VTS may use this element to describe the 471 authentication data and/or qualification information of the 472 Issuer. This implementation-specific information can be extended as 473 sub-elements using [XML-ns]. An example of such schema definition is 474 described in Section 8. 476 The <Issuer> element has a string-type "name" attribute that is used 477 to specify the name of the Issuer. 479 The <Issuer> element is defined by the following schema: 481 <element name="Issuer" type="gvl:RoleType"/> 482 The <RoleType> element type is defined in Section 6.4. 484 If the <Issuer> element is omitted, it MUST be interpreted that there 485 are no restrictions on the Issuer. 487 6.6 <Holder> 489 The <Holder> element may contain any elements that is used to specify 490 or restrict the Holder of the voucher. 492 The Holder of the voucher is generally managed by the VTS [VTS-API]. 493 There is no need to specify the Holder of the voucher using this 494 element if there are no restrictions on the Holder. 495 An implementation of a VTS may use this element to describe the 496 authentication data and/or qualification information of the 497 Holder. This implementation-specific information can be extended as 498 sub-elements using [XML-ns]. 500 The <Holder> element has a string-type "name" attribute that is used 501 to specify the name of the Holder. 503 The <Holder> element is defined by the following schema: 505 <element name="Holder" type="gvl:RoleType"/> 506 The <RoleType> element type is defined in Section 6.4. 508 If the <Holder> element is omitted, it MUST be interpreted that there 509 are no restrictions on the Holder. 511 6.7 <Collector> 513 The <Collector> element may contain any elements that is used to 514 specify or restrict the Collector of the voucher. 516 There is no need to specify the Collector of the voucher using this 517 element if there are no restrictions on the Collector. 518 An implementation of a VTS may use this element to describe the 519 authentication data and/or qualification information of the 520 Collector. This implementation-specific information can be extended 521 as sub-elements using [XML-ns]. 523 The <Collector> element has a string-type "name" attribute that is 524 used to specify the name of the Collector. 526 The <Collector> element is defined by the following schema: 528 <element name="Collector" type="gvl:RoleType"/> 529 The <RoleType> element type is defined in Section 6.4. 531 If the <Collector> element is omitted, it MUST be interpreted that 532 there are no restrictions on the Collector. 534 6.8 <Value> 536 The <Value> element optionally contains a <Fixed> or a <Ratio> 537 element but not both. These sub-elements are defined in the 538 following sections. 540 The <Value> element has a "type" attribute that is used to specify 541 the value process type. This attribute is provided to calculate the 542 amount paid when the vouchers are redeemed at Merchant site, etc. 544 The following identifiers are defined for the "type" attribute. 546 Exchange: Items specified in the <Merchandise> element can be 547 claimed in exchange for the voucher. If this type is selected, 548 neither <Ratio> nor <Fixed> element MUST be specified. Note that 549 this value process type has the same meaning as: 550 <Value type="discount"><Ratio percentage="100"/></Value> 552 Discount: Items specified in the <Merchandise> element can be 553 purchased at the discount price calculated by the <Ratio> or 554 <Fixed> element. 556 Monetary: Items specified in the <Merchandise> element can be 557 purchased using the value of the voucher. (Note: if the 558 <Merchandise> element is not specified, the voucher can be used 559 for any purchase.) If this type is selected, the <Fixed> element 560 MUST be specified. 562 The <Value> element also has a "spend" attribute that is used to 563 specify the number of vouchers to be redeemed for claiming the 564 goods, services, or monetary value specified. For example, if "n" 565 (>0) is specified, goods etc. can be claimed in exchange for "n 566 sheets of" vouchers. (Note: Multiple vouchers for the same Voucher 567 Component must exist in this case.) If "0" is specified, it can be 568 used repeatedly. 570 If the "spend" attribute is omitted or the whole element is omitted, 571 it MUST be interpreted that "1" is specified for the "spend" 572 attribute. 574 The <Value> element is defined by the following schema: 576 <element name="Value" type="gvl:ValueType"/> 577 <complexType name="ValueType"> 578 <sequence minOccurs="0"> 579 <choice> 580 <element name="Ratio" type="gvl:RatioValueType"/> 581 <element name="Fixed" type="gvl:FixedValueType"/> 582 </choice> 583 </sequence> 584 <attribute name="type" type="gvl:ValueProcessType" 585 use="required"/> 586 <attribute name="spend" type="nonNegativeInteger" 587 default="1"/> 588 </complexType> 590 The <ValueProcessType> element type is defined by the following 591 schema: 593 <simpleType name="ValueProcessType"> 594 <restriction base="string"> 595 <enumeration value="exchange"/> 596 <enumeration value="discount"/> 597 <enumeration value="monetary"/> 598 </restriction> 599 </simpleType> 601 6.8.1 <Ratio> 603 The <Ratio> element does not contain any contents. 605 The <Ratio> element has a "percentage" attribute that is used to 606 specify the discount ratio of the price of the corresponding 607 merchandize in percentage. 609 The <RatioValueType> element type is defined by the schema: 611 <complexType name="RatioValueType"> 612 <attribute name="percentage" use="required"> 613 <simpleType> 614 <restriction base="float"> 615 <maxInclusive value="100"/> 616 </restriction> 617 </simpleType> 618 </attribute> 619 </complexType> 621 6.8.2 <Fixed> 622 The <Fixed> element does not contain any contents. 624 The <Fixed> element has "currency" and "amount" attributes 625 and optionally a "decimalPower" attribute as follows: 627 Currency: Provides the unit of the monetary value in the three 628 letter ISO currency code [ISO4217]. For example, for US dollars 629 it is "USD". 631 Amount: Provides the amount of the monetary value per voucher. 633 DecimalPower: Provides the number of decimal digits from the 634 decimal point applied to the base for the "amount" attribute 635 above. If the "decimalPower" attribute is omitted, it MUST be 636 interpreted that "0" is specified for the "decimalPower" 637 attribute. 639 For example, with a dollar currency denominated in cents, "1" is 640 specifed for the "amount" attribute, and "-2" is specified for the 641 "decimalPower" attribute. Alternately, "0.01" is specified for 642 the "amount" attribute and the "decimalPower" attribute is omitted. 644 The <FixedValueType> type is defined by the following definition: 646 <complexType name="FixedValueType"> 647 <attribute name="currency" type="string" use="required"/> 648 <attribute name="amount" type="float" use="required"/> 649 <attribute name="decimalPower" type="short" default="0"/> 650 </complexType> 652 6.9 <Merchandise> 654 The <Merchandise> element may contain any elements used to specify or 655 restrict the goods or services rendered when the voucher is redeemed. 656 The sub-elements contained in this element are depending on the 657 application of the voucher and are left to the other domain-specific 658 specifications. Domain-specific elements can be extended as 659 sub-elements using [XML-ns]. 661 This element is intended to be interpreted by a collecting system. 662 An implementation of a wallet system does not have to use this 663 element. Any restrictions applied should also be described in the 664 <Description> element or the <Conditions> elements in natural 665 language form to enable users to check the restrictions. 667 The <Merchandise> element does not have any attribute. 669 The <Merchandise> element is defined by the following schema: 671 <element name="Merchandise" type="gvl:MerchandiseType"/> 672 <complexType name="MerchandiseType" mixed="true"> 673 <sequence> 674 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 676 </sequence> 677 </complexType> 679 6.10 <ValidPeriod> 681 The <VaridPeriod> element does not contain any contents. 683 The <ValidPeriod> element has dateTime-type "start" and "end" 684 attributes that are used to place limits on the validity of the 685 voucher. 687 The <ValidPeriod> element is defined by the following schema: 689 <element name="ValidPeriod" type="gvl:ValidPeriodType"/> 690 <complexType name="ValidPeriodType"> 691 <attribute name="start" type="dateTime"/> 692 <attribute name="end" type="dateTime"/> 693 </complexType> 695 If the "start" attribute is omitted, it MUST be interpreted that 696 the voucher is valid on any date up to the date (inclusive) 697 specified by the end attribute. If the "end" attribute is omitted, 698 it MUST be interpreted that the voucher is valid from the start 699 attribute with no expiry. If neither attribute is specified or the 700 whole element is omitted, it MUST be interpreted that the voucher 701 is valid at any time. 703 6.11 <Conditions> 705 The <Conditions> element contains any other restrictions or 706 conditions applied. This is intended to cover contracts between the 707 issuer and holder of the voucher in natural language form. 709 An implementation of a wallet system SHOULD provide a means of 710 displaying the text in this element. 712 The <Conditions> element has no attribute. 714 The <Conditions> element is defined by the following schema: 716 <element name="Conditions" type="string"/> 718 7. IANA Considerations 720 This document uses URNs to describe XML namespaces and XML schemas 721 conforming to a registry mechanism described in [XML-Registry]. 722 Two URI assignments are requested. 724 Registration request for the vts-lang namespace: 726 URI: urn:ietf:params:xml:ns:vts-lang 728 Registrant Contact: See the "Author's Address" section of this 729 document. 731 XML: None. Namespace URIs do not represent an XML specification. 733 Registration request for the vts-lang XML schema: 735 URI: urn:ietf:params:xml:schema:vts-lang 737 Registrant Contact: See the "Author's Address" section of this 738 document. 740 XML: 741 BEGIN 742 <?xml version="1.0"?> 744 <schema 745 targetNamespace="urn:ietf:params:xml:ns:vts-lang" 746 xmlns:gvl="urn:ietf:params:xml:ns:vts-lang" 747 xmlns="http://www.w3.org/2001/XMLSchema" 748 elementFormDefault="qualified"> 750 <element name="Voucher" type="gvl:VoucherType"/> 751 <complexType name="VoucherType"> 752 <sequence> 753 <element ref="gvl:Title"/> 754 <element ref="gvl:Description" minOccurs="0"/> 755 <element ref="gvl:Provider"/> 756 <element ref="gvl:Issuer" minOccurs="0"/> 757 <element ref="gvl:Holder" minOccurs="0"/> 758 <element ref="gvl:Collector" minOccurs="0"/> 759 <element ref="gvl:Value"/> 760 <element ref="gvl:Merchandise" minOccurs="0"/> 761 <element ref="gvl:ValidPeriod" minOccurs="0"/> 762 <element ref="gvl:Conditions" minOccurs="0"/> 763 </sequence> 764 </complexType> 766 <element name="Title" type="string"/> 768 <element name="Description" type="string"/> 770 <element name="Provider" type="gvl:RoleType"/> 771 <element name="Issuer" type="gvl:RoleType"/> 772 <element name="Holder" type="gvl:RoleType"/> 773 <element name="Collector" type="gvl:RoleType"/> 774 <complexType name="RoleType" mixed="true"> 775 <sequence> 776 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 777 </sequence> 778 <attribute name="name" type="string"/> 779 </complexType> 781 <element name="Value" type="gvl:ValueType"/> 782 <complexType name="ValueType"> 783 <sequence minOccurs="0"> 784 <choice> 785 <element name="Ratio" type="gvl:RatioValueType"/> 786 <element name="Fixed" type="gvl:FixedValueType"/> 787 </choice> 788 </sequence> 789 <attribute name="type" type="gvl:ValueProcessType" 790 use="required"/> 791 <attribute name="spend" type="nonNegativeInteger" 792 default="1"/> 793 </complexType> 795 <simpleType name="ValueProcessType"> 796 <restriction base="string"> 797 <enumeration value="exchange"/> 798 <enumeration value="discount"/> 799 <enumeration value="monetary"/> 800 </restriction> 801 </simpleType> 803 <complexType name="RatioValueType"> 804 <attribute name="percentage" use="required"> 805 <simpleType> 806 <restriction base="float"> 807 <maxInclusive value="100"/> 808 </restriction> 809 </simpleType> 810 </attribute> 811 </complexType> 813 <complexType name="FixedValueType"> 814 <attribute name="currency" type="string" use="required"/> 815 <attribute name="amount" type="float" use="required"/> 816 <attribute name="decimalPower" type="short" default="0"/> 817 </complexType> 819 <element name="Merchandise" type="gvl:MerchandiseType"/> 820 <complexType name="MerchandiseType" mixed="true"> 821 <sequence> 822 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 823 </sequence> 824 </complexType> 826 <element name="ValidPeriod" type="gvl:ValidPeriodType"/> 827 <complexType name="ValidPeriodType"> 828 <attribute name="start" type="dateTime"/> 829 <attribute name="end" type="dateTime"/> 830 </complexType> 832 <element name="Conditions" type="string"/> 833 </schema> 834 END 836 8. VTS Schema Example 838 An example of the schema definition for a VTS implementation is 839 described below: 841 <?xml version="1.0"?> 843 <schema 844 targetNamespace="http://www.example.com/vts" 845 xmlns:vts="http://www.example.com/vts" 846 xmlns="http://www.w3.org/2001/XMLSchema" 847 elementFormDefault="qualified"> 849 <element name="Version" type="string"/> 850 <element name="KeyInfo" type="hexBinary"/> 851 </schema> 853 Using this schema definition, the <vts:Version> can be used for 854 specifying the VTS version number and the <vts:KeyInfo> element can 855 be used for specifying the Issuer in the Voucher Component as shown 856 in Section 5. 858 9. Security Considerations 860 The VTS must provide a means of preventing forgery, alteration, 861 duplicate-redemption, reproduction of a voucher, and non-repudiation 862 of transactions as described in Section 3.2 of [VTS]. These security 863 requirements, however, mainly follow the VTS plug-ins and their 864 protocols. This document assumes that the VTS plug-ins are trusted 865 and installed by some means, e.g., manually checked like other 866 download applications. 868 The Voucher Component, however, defines restrictions on VTS Provider 869 (or VTS plug-in), and if this information is altered, incorrect VTS 870 plug-ins not accepted by the issuer could be used, and a forged 871 voucher could be verified as if it were valid. To prevent this 872 situation, the Voucher Component should be acquired securely, e.g., 873 downloaded from a trusted party using a secure communication channel, 874 such as [TLS], or [IPSEC], or secured by the digital signature of a 875 trusted party. 877 10. Normative References 879 [ISO4217] "Codes for the representation of currencies and funds", 880 ISO 4217, 1995. 882 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 883 Requirement Levels", BCP 14, RFC 2119, March 1997. 885 [URN] R. Moats, "URN Syntax", RFC2141, May 1997. 887 [URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents", 888 RFC2648, August 1999. 890 [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A 891 W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000. 893 [XML-ns] "Namespaces in XML", A W3C Recommendation, 894 <http://www.w3.org/TR/REC-xml-names>, January 1999. 896 [XML-Registry] M. Mealling, "The IETF XML Registry", RFC3688 897 January 2004. 899 [XML-Schema-1] H. Thompson, D. Beech, M. Maloney, and 900 N. Mendelsohn, "XML Schema Part 1: Structures W3C Recommendation.", 901 <http://www.w3.org/TR/xmlschema-1/>, May 2001. 903 [XML-Schema-2] P. Biron and A Malhotra, "XML Schema Part 2: 904 Datatypes W3C Recommendation.", 905 <http://www.w3.org/TR/xmlschema-2/>, May 2001. 907 11. Informational References 909 [VTS] K. Fujimura, D Eastlake, "Requirements and Design for Voucher 910 Trading System (VTS)", RFC3506, March 2003. 912 [IPSEC] R. Thayer, N. Doraswamy, and R. Glenn, "IP Security Document 913 Roadmap", RFC2411, November 1998 915 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, 916 January 1999. 918 [VTS-API] M. Terada and K. Fujimura, "Voucher Trading System 919 Application Programming Interface (VTS-API)", 920 draft-ietf-trade-voucher-vtsapi-06.txt, February 2004. 922 [XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature 923 Syntax and Processing", RFC3275, March 2002. 925 12. Author's Address 927 Ko Fujimura 928 NTT Corporation 929 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 930 Phone: +81-(0)46-859-3814 931 Fax: +81-(0)46-859-8329 932 Email: fujimura@isl.ntt.co.jp 934 Masayuki Terada 935 NTT DoCoMo, Inc. 936 3-5 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-8536 JAPAN 937 Phone: +81-(0)46-840-3809 938 Fax: +81-(0)46-840-3364 939 Email: te@mml.yrp.nttdocomo.co.jp 941 Full Copyright Statement 943 Copyright (C) The Internet Society (2004). All Rights Reserved. 945 This document and translations of it may be copied and furnished to 946 others, and derivative works that comment on or otherwise explain it 947 or assist in its implementation may be prepared, copied, published 948 and distributed, in whole or in part, without restriction of any 949 kind, provided that the above copyright notice and this paragraph are 950 included on all such copies and derivative works. However, this 951 document itself may not be modified in any way, such as by removing 952 the copyright notice or references to the Internet Society or other 953 Internet organizations, except as needed for the purpose of 954 developing Internet standards in which case the procedures for 955 copyrights defined in the Internet Standards process must be 956 followed, or as required to translate it into languages other than 957 English. 959 The limited permissions granted above are perpetual and will not be 960 revoked by the Internet Society or its successors or assigns. 962 This document and the information contained herein is provided on an 963 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 964 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 965 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 966 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 967 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.