idnits 2.17.1 draft-ietf-trade-voucher-lang-05.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 159 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 2003) is 7741 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 120, but not defined == Unused Reference: 'RFC2119' is defined on line 866, 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' == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 -- 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) == Outdated reference: A later version (-06) exists of draft-ietf-trade-voucher-vtsapi-05 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Trade Working Group February 2003 2 INTERNET-DRAFT Ko Fujimura 3 Masayuki Terada 4 Expires: August 2003 NTT 6 XML Voucher: Generic Voucher Language 7 9 Status of This Document 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Distribution of this document is unlimited. Please send comments to 31 the TRADE working group at , which may 32 be joined by sending a message with subject "subscribe" to . 35 Discussions of the TRADE working group are archived at 36 http://lists.elistx.com/archives/ietf-trade. 38 Abstract 40 This document specifies rules for defining voucher properties in XML 41 syntax. A voucher is a logical entity that represents a right to 42 claim goods or services. A voucher can be used to transfer a 43 wide-range of electronic-values, including coupons, tickets, loyalty 44 points, and gift certificates, which are often necessary to process 45 in the course of payment and/or delivery transactions. 47 Copyright (C) The Internet Society (2003). All Rights Reserved. 49 Acknowledgements 51 The following persons, in alphabetic order, contributed substantially 52 to the material herein: 54 Donald Eastlake 3rd 55 Ian Grigg 56 Renato Iannella 57 Yoshiaki Nakajima 59 Table of Contents 61 Status of this Memo ...............................................1 62 Abstract ..........................................................1 63 Acknowledgments ...................................................2 64 Table of Contents .................................................2 66 1. Introduction ...................................................3 67 2. Processing Model ...............................................3 68 3. Trust Model ....................................................4 69 4. Component Structure ............................................5 70 5. Syntax Overview and Examples ...................................7 71 6. Syntax and Semantics ...........................................8 72 6.1 ..................................................8 73 6.2 ....................................................9 74 6.3 <Description> ..............................................9 75 6.4 <Provider> .................................................9 76 6.5 <Issuer> ...................................................9 77 6.6 <Holder> ..................................................10 78 6.7 <Collector> ...............................................10 79 6.8 <Value> ...................................................11 80 6.8.1 <Ratio> .................................................12 81 6.8.2 <Fixed> .................................................12 82 6.9 <Merchandise> .............................................13 83 6.10 <ValidPeriod> ............................................14 84 6.11 <Conditions> .............................................14 85 7. IANA Considerations ...........................................14 86 8. VTS Schema Example ............................................17 87 9. Security Considerations .......................................17 88 10. Normative References ..........................................17 89 11. Informational References ......................................18 90 12. Author's Address ..............................................18 92 Full Copyright Statement ..........................................19 94 1. Introduction 96 This document, XML Voucher, specifies rules for defining voucher 97 properties in XML syntax. The motivation and background of the 98 specification are described in [GVT]. 100 A voucher is a logical entity that represents a certain right and 101 is logically managed by the Voucher Trading System (VTS). A voucher 102 is generated by the issuer, traded among users, and finally 103 collected by the collector using VTS. 105 This document defines the syntax and semantics of Voucher 106 Component, which defines voucher meaning and processing rules in 107 XML syntax [XML]. A Voucher Component define the properties that 108 must be satisfied to allow the voucher to be processed by VTS or 109 other trading systems, e.g., wallet or merchant system. VTS 110 definitions and models are also defined in [GVT]. 112 Note: This document uses "voucher" as an "instance of voucher" 113 whose meaning is defined by Voucher Component. In other words, 114 multiple vouchers can be issued and managed by the VTS using the 115 same Voucher Component. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 119 this document are to be interpreted as described in [RFC 2119] 121 2. Processing Model 123 There are several ways of implementing VTS and technologies are 124 continually changing. For discount coupons or event tickets, for 125 example, the smart-card-based offline VTS is often preferred, 126 whereas for bonds or securities, the centralized online VTS is 127 preferred. It is impractical to define standard protocols for 128 issuing, transferring, or redeeming vouchers at this moment. 130 To provide implementation flexibility, this document assumes a 131 modular wallet architecture that allows multiple VTS to be added as 132 plug-ins. In this architecture, instead of specifying a standard 133 voucher transfer protocol, two specifications, i.e., Voucher 134 Component and VTS-API specifications, are standardized (Figure 1). 136 After sender and receiver agree on what vouchers are to be traded 137 and which VTS is to be used, the issuing system or wallet system 138 requests the corresponding VTS plug-in to permit the issue, 139 transfer, or redeem transactions to be performed via the VTS 140 API. The VTS then rewrites the ownership of the vouchers using the 141 VTS-specific protocol. Finally, a completion event is sent to the 142 wallet systems or issuing/collecting systems. 144 This document describes the Voucher Component specification. The 145 VTS-API specification is defined in [VTS-API]. 147 Sender wallet/Issuing system Receiver wallet/Collecting system 148 +---------------------------+ +---------------------------+ 149 | | | | 150 | | Voucher Component | | 151 | | (Specifies VTS Provider and Promise) | | 152 | |-------------------------------------------------------->| | 153 | | | | | | 154 | | Intention to receive and payment (option) | | 155 | |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | | 156 | | | | | | 157 | | | | | | 158 | | Issue/transfer/ VTS | | VTS Register | | 159 | | redeem request plug-in | plug-in Listener(*1)| | 160 | |------------------>| | | |<------------------| | 161 | | (VTS-API) |<- - - - - - - ->| (VTS-API) | | 162 | | | VTS-specific | | | 163 | | | protocol if VTS | | | 164 | | | is distributed | | | 165 | | Result |<- - - - - - - ->| Notify(*2) | | 166 | |<------------------| | | |------------------>| | 167 +---------------------------+ +---------------------------+ 168 (*1) Registration is optional. Note also that the VTS plug-ins are 169 usually pre-registered when the wallet or collecting system 170 is started. 171 (*2) If a listener is registered. 173 Figure 1. Wallet architecture with VTS plug-ins 175 3. Trust Model 177 A voucher is trusted if the Issuer and VTS Provider are trusted, 178 since the Issuer is responsible for the contents of the voucher and 179 the VTS Provider is responsible for preventing ownership from being 180 assigned to multiple users. 182 The trust level required for Issuer and VTS Provider depends on the 183 type (or Promise) of the voucher. To provide the information needed 184 for verification, the conditions of Issuer and VTS Provider are 185 specified in the Voucher Component, and given as input to the 186 verifier, e.g., wallet system or other software. The trust of a 187 voucher is thus verified through the Voucher Component. This model 188 enables trading partners to verify their trust in the voucher 189 regardless of their trust in the partners. 191 This document assumes that the Voucher Component is the root of 192 trust. If a malicious user could alter the Voucher Component, a 193 forged voucher, could be verified as valid. 195 The Voucher Component is usually delivered from the trusted VTS 196 Provider, Issuer or trusted third party using a secure 197 communication channel, such as [XMLDSIG], [TLS], or [IPSEC]. 198 Delivery of the Voucher Component is beyond the scope of this 199 document. 201 Note: The Voucher Component does not have to be sent from the 202 sender of the voucher. Note also that a set of trusted Voucher 203 Components can be downloaded before conducting a transaction. 205 4. Component Structure 207 The Voucher Component provides the information needed to identify 208 the monetary value or merchandize rendered when the voucher is 209 redeemed. It includes: 211 o How much value/items can be claimed in exchange for the voucher 213 o Restrictions applied to the voucher 214 - Participants (VTS Provider, Issuer, Holder, and Collector) 215 - Objects (merchandise) to be claimed 216 - Time when valid (validity period) 217 - Others 219 The Voucher Component also provides common properties useful for 220 displaying and manipulating the contents of wallet systems. It 221 includes the title and description of each voucher. 223 The Voucher Component contains the Title Component, Description 224 Component, Provider Component, Issuer Component, Holder Component, 225 Collector Component, Value Component, Merchandise Component, 226 ValidPeriod Component, and Condition Component as follows: 228 Title Component 230 Provides the title of the voucher. This is mainly for listing 231 the entities stored in a wallet system. 233 Description Component 235 Provides a short description of the voucher. This is mainly for 236 listing the entities stored in a wallet system. 238 Provider Component 240 Provides restrictions on which VTS Provider (or VTS plug-in) can 241 be used for trading the voucher. 243 Issuer Component 245 Provides restrictions on the Issuer of the voucher. 247 Holder Component 249 Provides restrictions on the Holder of the voucher. 251 Collector Component 252 Provides restrictions on the Collector of the voucher. 254 Value Component 256 Provides the value of each voucher. There are two types of 257 values, i.e., fixed and ratio values. For a fixed value, the 258 currency and the figure is specified. For a ratio value, the 259 discount ratio of the corresponding merchandize is specified. 261 The Value Component also indicates the number of vouchers to be 262 redeemed for claiming the merchandise or monetary value specified 263 in Merchandise Component or Value Component. If "n"(>0) is 264 specified, the merchandize or monetary value can be claimed in 265 exchange for "n sheets of" vouchers. If "0" is specified, it 266 can be used repeatedly. 268 Merchandise Component 270 Provides restrictions on the object to be claimed. 271 Domain-specific meaning of the voucher, e.g., reference number of 272 the merchandize or seat number for an event ticket, is specified 273 to identify the merchandize rendered when the voucher is 274 redeemed. 276 ValidPeriod Component 278 Provides restrictions on the validity period of the voucher, 279 i.e., start date and end date. 281 Condition Component 283 Provides any other applicable restrictions. This is intended to 284 cover contracts between the issuer and holder of the 285 voucher in natural language form. 287 Using the above Components, semantics for diverse types of vouchers 288 can be defined as shown in Table 1. 290 +----------------+--------------------------------+---------------+ 291 | | Value | Restrictions | 292 | +-----+---------------+----------+---------------+ 293 | Examples |Ratio| Fixed |Number | Merchandise | 294 | | +------+--------+Needed for| | 295 | | |Amount|Currency|redemption| | 296 +----------------+-----+------+--------+----------+---------------+ 297 |Gift certificate| | 25 | USD | 1 |(Not specified)| 298 |Loyalty point | | 1 | AUD | 10 |(Not specified)| 299 |Member card | 20%| | | 0 |(Not specified)| 300 |Coupon | 30%| | | 1 |Beef 500g | 301 |Event ticket | 100%| | | 1 |Hall A, S ,K23 | 302 |Exchange ticket | 100%| | | 1 |ISBN:0071355014| 303 +----------------+-----+------+--------+----------+---------------+ 304 Table 1. Examples of vouchers and their properties 306 5. Syntax Overview and Examples 308 This section provides an overview and examples of Voucher 309 Component. The formal syntax and semantics are found in Sections 6 310 and 7. 312 Voucher Components are represented by the <Voucher> element which 313 has the following structure (where "?" denotes zero or one 314 occurrence): 316 <Voucher> 317 (Title) 318 (Description)? 319 (Provider) 320 (Issuer)? 321 (Holder)? 322 (Collector)? 323 (Value) 324 (Merchandise)? 325 (ValidPeriod)? 326 (Conditions)? 327 </Voucher> 329 An example of a Voucher Component is described below. This is an 330 example of a five dollar discount coupon for specific merchandize, 331 a book with ISBN number 0071355014. The coupon is valid from April 332 1st in 2001 to March 31st in 2002. To claim this offer, one voucher 333 must be spent. 335 <?xml version="1.0"?> 336 <Voucher xmlns="urn:ietf:params:xml:schema:vts-lang" 337 xmlns:vts="http://www.example.com/vts"> 338 <Title>IOTP Book Coupon 339 $5 off IOTP Book 340 341 VE2.31 342 343 344 345 1DA8DFCF95521014BBB7171B95545E8D61AE803F 346 347 348 349 350 351 352 353 355 356 357 358 The value of this coupon is subject to tax. 359 360 362 6. Syntax and Semantics 364 The general structure of an XML voucher is described in Component 365 Structure (section 4). This section details the Voucher Component 366 features. Features described in this section MUST be implemented 367 unless otherwise indicated. The syntax is defined via 368 [XML-Schema-1] [XML-Schema-2]. For clarity, unqualified elements in 369 schema definitions are in the XML schema namespace: 371 xmlns="http://www.w3.org/2001/XMLSchema" 373 References to XML Voucher schema defined herein use the prefix 374 "gvl" and are in the namespace: 376 xmlns:gvl="urn:ietf:params:xml:schema:vts-lang" 378 This namespace URI for elements defined by this document is a URN 379 [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] 380 and extended by [XML-Registry]. 382 This namespace is also used for unqualified elements in voucher 383 examples. 385 6.1 387 The element contains , <Provider>, and <Value> 388 elements and optionally contains <Description>, <Issuer>, <Holder>, 389 <Collector>, <ValidPeriod>, and <Condition> elements. These 390 sub-elements are defined in the following sections. 392 The <Voucher> element is defined by the following schema: 394 <element name="Voucher" type="gvl:VoucherType"/> 395 <complexType name="VoucherType"> 396 <sequence> 397 <element ref="gvl:Title"/> 398 <element ref="gvl:Description" minOccurs="0"/> 399 <element ref="gvl:Provider"/> 400 <element ref="gvl:Issuer" minOccurs="0"/> 401 <element ref="gvl:Holder" minOccurs="0"/> 402 <element ref="gvl:Collector" minOccurs="0"/> 403 <element ref="gvl:Value"/> 404 <element ref="gvl:Merchandise" minOccurs="0"/> 405 <element ref="gvl:ValidPeriod" minOccurs="0"/> 406 <element ref="gvl:Conditions" minOccurs="0"/> 407 </sequence> 408 </complexType> 410 6.2 <Title> 412 The <Title> element contains a simpletext title of the voucher. 413 This is mainly for listing the entities stored in a wallet system. 415 The <Title> element has no attribute. 417 The <Title> element is defined by the following schema: 419 <element name="Title" type="string"/> 421 6.3 <Description> 423 The <Description> element contains a simpletext description of the 424 voucher. This is mainly for listing the entities stored in a 425 wallet system. 427 The <Description> element has no attribute. 429 The <Description> element is defined by the following schema: 431 <element name="Description" type="string"/> 433 6.4 <Provider> 435 The <Provider> element may contain any elements that is used to 436 specify or restrict the VTS Provider of the voucher. The 437 sub-elements contained in this element depend on the implementation 438 of the VTS. 440 An implementation of a wallet system may use this information to 441 identify and/or authenticate the VTS Provider when the VTS plug-in is 442 registered (See Section 7 of [VTS-API]). These 443 implementation-specific elements of the VTS can be extended using 444 [XML-ns]. An example of such schema definition is described in 445 Section 8. 447 The <Provider> element has a string-type "name" attribute that is 448 used to specify the name of the VTS Provider. 450 The <Provider> element is defined by the following schema: 452 <element name="Provider" type="gvl:RoleType"/> 453 <complexType name="RoleType" mixed="true"> 454 <sequence> 455 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 456 </sequence> 457 <attribute name="name" type="string"/> 458 </complexType> 460 6.5 <Issuer> 461 The <Issuer> element may contain any element that is used to specify 462 or restrict the Issuer of the voucher. 464 The Issuer of the voucher is generally managed by the VTS [VTS-API]. 465 There is no need to specify the Issuer of the voucher using this 466 element if there are no restrictions on the Issuer. 467 An implementation of a VTS may use this element to describe the 468 authentication data and/or qualification information of the 469 Issuer. This implementation-specific information can be extended as 470 sub-elements using [XML-ns]. An example of such schema definition is 471 described in Section 8. 473 The <Issuer> element has a string-type "name" attribute that is used 474 to specify the name of the Issuer. 476 The <Issuer> element is defined by the following schema: 478 <element name="Issuer" type="gvl:RoleType"/> 479 The <RoleType> element type is defined in Section 6.4. 481 If the <Issuer> element is omitted, it MUST be interpreted that there 482 are no restrictions on the Issuer. 484 6.6 <Holder> 486 The <Holder> element may contain any elements that is used to specify 487 or restrict the Holder of the voucher. 489 The Holder of the voucher is generally managed by the VTS [VTS-API]. 490 There is no need to specify the Holder of the voucher using this 491 element if there are no restrictions on the Holder. 492 An implementation of a VTS may use this element to describe the 493 authentication data and/or qualification information of the 494 Holder. This implementation-specific information can be extended as 495 sub-elements using [XML-ns]. 497 The <Holder> element has a string-type "name" attribute that is used 498 to specify the name of the Holder. 500 The <Holder> element is defined by the following schema: 502 <element name="Holder" type="gvl:RoleType"/> 503 The <RoleType> element type is defined in Section 6.4. 505 If the <Holder> element is omitted, it MUST be interpreted that there 506 are no restrictions on the Holder. 508 6.7 <Collector> 510 The <Collector> element may contain any elements that is used to 511 specify or restrict the Collector of the voucher. 513 There is no need to specify the Collector of the voucher using this 514 element if there are no restrictions on the Collector. 515 An implementation of a VTS may use this element to describe the 516 authentication data and/or qualification information of the 517 Collector. This implementation-specific information can be extended 518 as sub-elements using [XML-ns]. 520 The <Collector> element has a string-type "name" attribute that is 521 used to specify the name of the Collector. 523 The <Collector> element is defined by the following schema: 525 <element name="Collector" type="gvl:RoleType"/> 526 The <RoleType> element type is defined in Section 6.4. 528 If the <Collector> element is omitted, it MUST be interpreted that 529 there are no restrictions on the Collector. 531 6.8 <Value> 533 The <Value> element optionally contains a <Fixed> or a <Ratio> 534 element but not both. These sub-elements are defined in the 535 following sections. 537 The <Value> element has a "type" attribute that is used to specify 538 the value process type. This attribute is provided to calculate the 539 amount paid when the vouchers are redeemed at Merchant site, etc. 541 The following identifiers are defined for the "type" attribute. 543 Exchange: Items specified in the <Merchandise> element can be 544 claimed in exchange for the voucher. If this type is selected, 545 neither <Ratio> nor <Fixed> element MUST be specified. Note that 546 this value process type has the same meaning as: 547 <Value type="discount"><Ratio percentage="100"/></Value> 549 Discount: Items specified in the <Merchandise> element can be 550 purchased at the discount price calculated by the <Ratio> or 551 <Fixed> element. 553 Monetary: Items specified in the <Merchandise> element can be 554 purchased using the value of the voucher. (Note: if the 555 <Merchandise> element is not specified, the voucher can be used 556 for any purchase.) If this type is selected, the <Fixed> element 557 MUST be specified. 559 The <Value> element also has a "spend" attribute that is used to 560 specify the number of vouchers to be redeemed for claiming the 561 goods, services, or monetary value specified. For example, if "n" 562 (>0) is specified, goods etc. can be claimed in exchange for "n 563 sheets of" vouchers. (Note: Multiple vouchers for the same Voucher 564 Component must exist in this case.) If "0" is specified, it can be 565 used repeatedly. 567 If the "spend" attribute is omitted or the whole element is omitted, 568 it MUST be interpreted that "1" is specified for the "spend" 569 attribute. 571 The <Value> element is defined by the following schema: 573 <element name="Value" type="gvl:ValueType"/> 574 <complexType name="ValueType"> 575 <sequence minOccurs="0"> 576 <choice> 577 <element name="Ratio" type="gvl:RatioValueType"/> 578 <element name="Fixed" type="gvl:FixedValueType"/> 579 </choice> 580 </sequence> 581 <attribute name="type" type="gvl:ValueProcessType" 582 use="required"/> 583 <attribute name="spend" type="nonNegativeInteger" 584 default="1"/> 585 </complexType> 587 The <ValueProcessType> element type is defined by the following 588 schema: 590 <simpleType name="ValueProcessType"> 591 <restriction base="string"> 592 <enumeration value="exchange"/> 593 <enumeration value="discount"/> 594 <enumeration value="monetary"/> 595 </restriction> 596 </simpleType> 598 6.8.1 <Ratio> 600 The <Ratio> element does not contain any contents. 602 The <Ratio> element has a "percentage" attribute that is used to 603 specify the discount ratio of the price of the corresponding 604 merchandize in percentage. 606 The <RatioValueType> element type is defined by the schema: 608 <complexType name="RatioValueType"> 609 <attribute name="percentage" use="required"> 610 <simpleType> 611 <restriction base="float"> 612 <maxInclusive value="100"/> 613 </restriction> 614 </simpleType> 615 </attribute> 616 </complexType> 618 6.8.2 <Fixed> 619 The <Fixed> element does not contain any contents. 621 The <Fixed> element has "currency" and "amount" attributes 622 and optionally a "decimalPower" attribute as follows: 624 Currency: Provides the unit of the monetary value in the three 625 letter ISO currency code [ISO4217]. For example, for US dollars 626 it is "USD". 628 Amount: Provides the amount of the monetary value per voucher. 630 DecimalPower: Provides the number of decimal digits from the 631 decimal point applied to the base for the "amount" attribute 632 above. If the "decimalPower" attribute is omitted, it MUST be 633 interpreted that "0" is specified for the "decimalPower" 634 attribute. 636 For example, with a dollar currency denominated in cents, "1" is 637 specifed for the "amount" attribute, and "-2" is specified for the 638 "decimalPower" attribute. Alternately, "0.01" is specified for 639 the "amount" attribute and the "decimalPower" attribute is omitted. 641 The <FixedValueType> type is defined by the following definition: 643 <complexType name="FixedValueType"> 644 <attribute name="currency" type="string" use="required"/> 645 <attribute name="amount" type="float" use="required"/> 646 <attribute name="decimalPower" type="short" default="0"/> 647 </complexType> 649 6.9 <Merchandise> 651 The <Merchandise> element may contain any elements used to specify or 652 restrict the goods or services rendered when the voucher is redeemed. 653 The sub-elements contained in this element are depending on the 654 application of the voucher and are left to the other domain-specific 655 specifications. Domain-specific elements can be extended as 656 sub-elements using [XML-ns]. 658 The <Merchandise> element does not have any attribute. 660 The <Merchandise> element is defined by the following schema: 662 <element name="Merchandise" type="gvl:MerchandiseType"/> 663 <complexType name="MerchandiseType" mixed="true"> 664 <sequence> 665 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 666 </sequence> 667 </complexType> 669 If the <Merchandise> element is omitted, it will be generally 670 interpreted that there is no restriction on the merchandise when 671 using the voucher. 673 6.10 <ValidPeriod> 675 The <VaridPeriod> element does not contain any contents. 677 The <ValidPeriod> element has dateTime-type "start" and "end" 678 attributes that are used to place limits on the validity of the 679 voucher. 681 The <ValidPeriod> element is defined by the following schema: 683 <element name="ValidPeriod" type="gvl:ValidPeriodType"/> 684 <complexType name="ValidPeriodType"> 685 <attribute name="start" type="dateTime"/> 686 <attribute name="end" type="dateTime"/> 687 </complexType> 689 If the "start" attribute is omitted, it MUST be interpreted that 690 the voucher is valid on any date up to the date (inclusive) 691 specified by the end attribute. If the "end" attribute is omitted, 692 it MUST be interpreted that the voucher is valid from the start 693 attribute with no expiry. If neither attribute is specified or the 694 whole element is omitted, it MUST be interpreted that the voucher 695 is valid at any time. 697 6.10 <Conditions> 699 The <Conditions> element may contain any element used to specify 700 any other restrictions or conditions applied that limit the use of 701 the voucher. The sub-elements contained in this element are 702 depending on the application of the voucher and are left to the 703 other domain-specific specifications. Domain-specific elements can 704 be extended as sub-elements using [XML-ns]. 706 The <Conditions> element does not have any attribute. 708 The <Conditions> element is defined by the following schema: 710 <element name="Conditions" type="gvl:ConditionsType"/> 711 <complexType name="ConditionsType" mixed="true"> 712 <sequence> 713 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 714 </sequence> 715 </complexType> 717 If the <Conditions> element is omitted, it will be generally 718 interpreted that there are no other restrictions or conditions on 719 using the voucher. 721 7. IANA Considerations 723 This document calls for IANA to register a new XML schema with the 724 URN. The registation form [XML-Registry] for this is below: 726 URI 727 urn:ietf:params:xml:schema:vts-lang 729 Registrant Contact 730 See the "Author's Address" section of this document. 732 XML 733 BEGIN 734 <?xml version="1.0"?> 736 <schema 737 targetNamespace="urn:ietf:params:xml:schema:vts-lang" 738 xmlns:gvl="urn:ietf:params:xml:schema:vts-lang" 739 xmlns="http://www.w3.org/2001/XMLSchema" 740 elementFormDefault="qualified"> 742 <element name="Voucher" type="gvl:VoucherType"/> 743 <complexType name="VoucherType"> 744 <sequence> 745 <element ref="gvl:Title"/> 746 <element ref="gvl:Description" minOccurs="0"/> 747 <element ref="gvl:Provider"/> 748 <element ref="gvl:Issuer" minOccurs="0"/> 749 <element ref="gvl:Holder" minOccurs="0"/> 750 <element ref="gvl:Collector" minOccurs="0"/> 751 <element ref="gvl:Value"/> 752 <element ref="gvl:Merchandise" minOccurs="0"/> 753 <element ref="gvl:ValidPeriod" minOccurs="0"/> 754 <element ref="gvl:Conditions" minOccurs="0"/> 755 </sequence> 756 </complexType> 758 <element name="Title" type="string"/> 760 <element name="Description" type="string"/> 762 <element name="Provider" type="gvl:RoleType"/> 763 <element name="Issuer" type="gvl:RoleType"/> 764 <element name="Holder" type="gvl:RoleType"/> 765 <element name="Collector" type="gvl:RoleType"/> 766 <complexType name="RoleType" mixed="true"> 767 <sequence> 768 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 769 </sequence> 770 <attribute name="name" type="string"/> 771 </complexType> 773 <element name="Value" type="gvl:ValueType"/> 774 <complexType name="ValueType"> 775 <sequence minOccurs="0"> 776 <choice> 777 <element name="Ratio" type="gvl:RatioValueType"/> 778 <element name="Fixed" type="gvl:FixedValueType"/> 779 </choice> 780 </sequence> 781 <attribute name="type" type="gvl:ValueProcessType" 782 use="required"/> 783 <attribute name="spend" type="nonNegativeInteger" 784 default="1"/> 785 </complexType> 787 <simpleType name="ValueProcessType"> 788 <restriction base="string"> 789 <enumeration value="exchange"/> 790 <enumeration value="discount"/> 791 <enumeration value="monetary"/> 792 </restriction> 793 </simpleType> 795 <complexType name="RatioValueType"> 796 <attribute name="percentage" use="required"> 797 <simpleType> 798 <restriction base="float"> 799 <maxInclusive value="100"/> 800 </restriction> 801 </simpleType> 802 </attribute> 803 </complexType> 805 <complexType name="FixedValueType"> 806 <attribute name="currency" type="string" use="required"/> 807 <attribute name="amount" type="float" use="required"/> 808 <attribute name="decimalPower" type="short" default="0"/> 809 </complexType> 811 <element name="Merchandise" type="gvl:MerchandiseType"/> 812 <complexType name="MerchandiseType" mixed="true"> 813 <sequence> 814 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 815 </sequence> 816 </complexType> 818 <element name="ValidPeriod" type="gvl:ValidPeriodType"/> 819 <complexType name="ValidPeriodType"> 820 <attribute name="start" type="dateTime"/> 821 <attribute name="end" type="dateTime"/> 822 </complexType> 824 <element name="Conditions" type="gvl:ConditionsType"/> 825 <complexType name="ConditionsType" mixed="true"> 826 <sequence> 827 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 828 </sequence> 829 </complexType> 831 </schema> 832 END 834 8. VTS Schema Example 836 An example of the schema definition for a VTS implementation is 837 described below: 839 <?xml version="1.0"?> 841 <schema 842 targetNamespace="http://www.example.com/vts" 843 xmlns:vts="http://www.example.com/vts" 844 xmlns="http://www.w3.org/2001/XMLSchema" 845 elementFormDefault="qualified"> 847 <element name="Version" type="string"/> 848 <element name="KeyInfo" type="hexBinary"/> 849 </schema> 851 Using this schema definition, the <vts:Version> can be used for 852 specifying the VTS version number and the <vts:KeyInfo> element can 853 be used for specifying the Issuer in the Voucher Component as shown 854 in Section 5. 856 9. Security Considerations 858 Security issues for delivering Voucher Components are discussed in 859 Section 3. 861 10. Normative References 863 [ISO4217] "Codes for the representation of currencies and funds", 864 ISO 4217, 1995. 866 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, March 1997. 869 [URN] R. Moats, "URN Syntax", RFC2141, May 1997. 871 [URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents", 872 RFC2648, August 1999. 874 [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A 875 W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000. 877 [XML-ns] "Namespaces in XML", A W3C Recommendation, 878 <http://www.w3.org/TR/REC-xml-names>, January 1999. 880 [XML-Registry] M. Mealing, "The IETF XML Registry", 881 draft-mealling-iana-xmlns-registry-04, June 2002. In RFC Editor 882 queue. 884 [XML-Schema-1] H. Thompson, D. Beech, M. Maloney, and 885 N. Mendelsohn, "XML Schema Part 1: Structures W3C Recommendation.", 886 <http://www.w3.org/TR/xmlschema-1/>, May 2001. 888 [XML-Schema-2] P. Biron and A Malhotra, "XML Schema Part 2: 889 Datatypes W3C Recommendation.", 890 <http://www.w3.org/TR/xmlschema-2/>, May 2001. 892 11. Informational References 894 [GVT] K. Fujimura, "Requirements and Design for Voucher Trading 895 System (VTS)", draft-ietf-trade-drt-requirements-04.txt, July 896 2002. In RFC Editor queue. 898 [IPSEC] R. Thayer, N. Doraswamy, and R. Glenn, "IP Security Document 899 Roadmap", RFC2411, November 1998 901 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, 902 January 1999. 904 [VTS-API] M. Terada and K. Fujimura, "Voucher Trading System 905 Application Programming Interface (VTS-API)", 906 draft-ietf-trade-voucher-vtsapi-05.txt, February 2003. 908 [XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature 909 Syntax and Processing", RFC3275, March 2002. 911 12. Author's Address 913 Ko Fujimura and Masayuki Terada 914 NTT Corporation 915 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 916 Phone: +81-(0)46-859-3814 917 Fax: +81-(0)46-859-8329 918 Email: fujimura@isl.ntt.co.jp, terada@isl.ntt.co.jp 920 Full Copyright Statement 922 Copyright (C) The Internet Society (2003). All Rights Reserved. 924 This document and translations of it may be copied and furnished to 925 others, and derivative works that comment on or otherwise explain it 926 or assist in its implementation may be prepared, copied, published 927 and distributed, in whole or in part, without restriction of any 928 kind, provided that the above copyright notice and this paragraph are 929 included on all such copies and derivative works. However, this 930 document itself may not be modified in any way, such as by removing 931 the copyright notice or references to the Internet Society or other 932 Internet organizations, except as needed for the purpose of 933 developing Internet standards in which case the procedures for 934 copyrights defined in the Internet Standards process must be 935 followed, or as required to translate it into languages other than 936 English. 938 The limited permissions granted above are perpetual and will not be 939 revoked by the Internet Society or its successors or assigns. 941 This document and the information contained herein is provided on an 942 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 943 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 944 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 945 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 946 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.