idnits 2.17.1 draft-ietf-trade-voucher-lang-04.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 156 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 (December 2002) is 7802 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 117, 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-06 ** 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-03 ** 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-04 -- 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 (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Trade Working Group December 2002 2 INTERNET-DRAFT Ko Fujimura 3 Masayuki Terada 4 Expires: June 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 Acknowledgements 49 The following persons, in alphabetic order, contributed substantially 50 to the material herein: 52 Donald Eastlake 3rd 53 Ian Grigg 54 Renato Iannella 55 Yoshiaki Nakajima 57 Table of Contents 59 Status of this Memo ...............................................1 60 Abstract ..........................................................1 61 Acknowledgments ...................................................2 62 Table of Contents .................................................2 64 1. Introduction ...................................................3 65 2. Processing Model ...............................................3 66 3. Trust Model ....................................................4 67 4. Component Structure ............................................5 68 5. Syntax Overview and Examples ...................................7 69 6. Syntax and Semantics ...........................................8 70 6.1 ..................................................8 71 6.2 ....................................................9 72 6.3 <Description> ..............................................9 73 6.4 <Provider> .................................................9 74 6.5 <Issuer> ...................................................9 75 6.6 <Holder> ..................................................10 76 6.7 <Collector> ...............................................10 77 6.8 <Value> ...................................................11 78 6.8.1 <Ratio> .................................................12 79 6.8.2 <Fixed> .................................................12 80 6.9 <Merchandise> .............................................13 81 6.10 <ValidPeriod> ............................................14 82 6.11 <Conditions> .............................................14 83 7. IANA Considerations ...........................................14 84 8. VTS Schema Example ............................................17 85 9. Security Considerations .......................................17 86 10. References ....................................................17 87 11. Author's Address ..............................................18 89 Full Copyright Statement ..........................................19 91 1. Introduction 93 This document, XML Voucher, specifies rules for defining voucher 94 properties in XML syntax. The motivation and background of the 95 specification are described in [GVT]. 97 A voucher is a logical entity that represents a certain right and 98 is logically managed by the Voucher Trading System (VTS). A voucher 99 is generated by the issuer, traded among users, and finally 100 collected by the collector using VTS. 102 This document defines the syntax and semantics of Voucher 103 Component, which defines voucher meaning and processing rules in 104 XML syntax [XML]. A Voucher Component define the properties that 105 must be satisfied to allow the voucher to be processed by VTS or 106 other trading systems, e.g., wallet or merchant system. VTS 107 definitions and models are also defined in [GVT]. 109 Note: This document uses "voucher" as an "instance of voucher" 110 whose meaning is defined by Voucher Component. In other words, 111 multiple vouchers can be issued and managed by the VTS using the 112 same Voucher Component. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 116 this document are to be interpreted as described in [RFC 2119] 118 2. Processing Model 120 There are several ways of implementing VTS and technologies are 121 continually changing. For discount coupons or event tickets, for 122 example, the smart-card-based offline VTS is often preferred, 123 whereas for bonds or securities, the centralized online VTS is 124 preferred. It is impractical to define standard protocols for 125 issuing, transferring, or redeeming vouchers at this moment. 127 To provide implementation flexibility, this document assumes a 128 modular wallet architecture that allows multiple VTS to be added as 129 plug-ins. In this architecture, instead of specifying a standard 130 voucher transfer protocol, two specifications, i.e., Voucher 131 Component and VTS-API specifications, are standardized (Figure 1). 133 After sender and receiver agree on what vouchers are to be traded 134 and which VTS is to be used, the issuing system or wallet system 135 requests the corresponding VTS plug-in to permit the issue, 136 transfer, or redeem transactions to be performed via the VTS 137 API. The VTS then rewrites the ownership of the vouchers using the 138 VTS-specific protocol. Finally, a completion event is sent to the 139 wallet systems or issuing/collecting systems. 141 This document describes the Voucher Component specification. The 142 VTS-API specification is defined in [VTS-API]. 144 Sender wallet/Issuing system Receiver wallet/Collecting system 145 +---------------------------+ +---------------------------+ 146 | | | | 147 | | Voucher Component | | 148 | | (Specifies VTS Provider and Promise) | | 149 | |-------------------------------------------------------->| | 150 | | | | | | 151 | | Intention to receive and payment (option) | | 152 | |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | | 153 | | | | | | 154 | | | | | | 155 | | Issue/transfer/ VTS | | VTS Register | | 156 | | redeem request plug-in | plug-in Listener(*1)| | 157 | |------------------>| | | |<------------------| | 158 | | (VTS-API) |<- - - - - - - ->| (VTS-API) | | 159 | | | VTS-specific | | | 160 | | | protocol if VTS | | | 161 | | | is distributed | | | 162 | | Result |<- - - - - - - ->| Notify(*2) | | 163 | |<------------------| | | |------------------>| | 164 +---------------------------+ +---------------------------+ 165 (*1) Registration is optional. Note also that the VTS plug-ins are 166 usually pre-registered when the wallet or collecting system 167 is started. 168 (*2) If a listener is registered. 170 Figure 1. Wallet architecture with VTS plug-ins 172 3. Trust Model 174 A voucher is trusted if the Issuer and VTS Provider are trusted, 175 since the Issuer is responsible for the contents of the voucher and 176 the VTS Provider is responsible for preventing ownership from being 177 assigned to multiple users. 179 The trust level required for Issuer and VTS Provider depends on the 180 type (or Promise) of the voucher. To provide the information needed 181 for verification, the conditions of Issuer and VTS Provider are 182 specified in the Voucher Component, and given as input to the 183 verifier, e.g., wallet system or other software. The trust of a 184 voucher is thus verified through the Voucher Component. This model 185 enables trading partners to verify their trust in the voucher 186 regardless of their trust in the partners. 188 This document assumes that the Voucher Component is the root of 189 trust. If a malicious user could alter the Voucher Component, a 190 forged voucher, could be verified as valid. 192 The Voucher Component is usually delivered from the trusted VTS 193 Provider, Issuer or trusted third party using a secure 194 communication channel, such as [XMLDSIG], [TLS], or [IPSEC]. 195 Delivery of the Voucher Component is beyond the scope of this 196 document. 198 Note: The Voucher Component does not have to be sent from the 199 sender of the voucher. Note also that a set of trusted Voucher 200 Components can be downloaded before conducting a transaction. 202 4. Component Structure 204 The Voucher Component provides the information needed to identify 205 the monetary value or merchandize rendered when the voucher is 206 redeemed. It includes: 208 o How much value/items can be claimed in exchange for the voucher 210 o Restrictions applied to the voucher 211 - Participants (VTS Provider, Issuer, Holder, and Collector) 212 - Objects (merchandise) to be claimed 213 - Time when valid (validity period) 214 - Others 216 The Voucher Component also provides common properties useful for 217 displaying and manipulating the contents of wallet systems. It 218 includes the title and description of each voucher. 220 The Voucher Component contains the Title Component, Description 221 Component, Provider Component, Issuer Component, Holder Component, 222 Collector Component, Value Component, Merchandise Component, 223 ValidPeriod Component, and Condition Component as follows: 225 Title Component 227 Provides the title of the voucher. This is mainly for listing 228 the entities stored in a wallet system. 230 Description Component 232 Provides a short description of the voucher. This is mainly for 233 listing the entities stored in a wallet system. 235 Provider Component 237 Provides restrictions on which VTS Provider (or VTS plug-in) can 238 be used for trading the voucher. 240 Issuer Component 242 Provides restrictions on the Issuer of the voucher. 244 Holder Component 246 Provides restrictions on the Holder of the voucher. 248 Collector Component 249 Provides restrictions on the Collector of the voucher. 251 Value Component 253 Provides the value of each voucher. There are two types of 254 values, i.e., fixed and ratio values. For a fixed value, the 255 currency and the figure is specified. For a ratio value, the 256 discount ratio of the corresponding merchandize is specified. 258 The Value Component also indicates the number of vouchers to be 259 redeemed for claiming the merchandise or monetary value specified 260 in Merchandise Component or Value Component. If "n"(>0) is 261 specified, the merchandize or monetary value can be claimed in 262 exchange for "n sheets of" vouchers. If "0" is specified, it 263 can be used repeatedly. 265 Merchandise Component 267 Provides restrictions on the object to be claimed. 268 Domain-specific meaning of the voucher, e.g., reference number of 269 the merchandize or seat number for an event ticket, is specified 270 to identify the merchandize rendered when the voucher is 271 redeemed. 273 ValidPeriod Component 275 Provides restrictions on the validity period of the voucher, 276 i.e., start date and end date. 278 Condition Component 280 Provides any other applicable restrictions. This is intended to 281 cover contracts between the issuer and holder of the 282 voucher in natural language form. 284 Using the above Components, semantics for diverse types of vouchers 285 can be defined as shown in Table 1. 287 +----------------+--------------------------------+---------------+ 288 | | Value | Restrictions | 289 | +-----+---------------+----------+---------------+ 290 | Examples |Ratio| Fixed |Number | Merchandise | 291 | | +------+--------+Needed for| | 292 | | |Amount|Currency|redemption| | 293 +----------------+-----+------+--------+----------+---------------+ 294 |Gift certificate| | 25 | USD | 1 |(Not specified)| 295 |Loyalty point | | 1 | AUD | 10 |(Not specified)| 296 |Member card | 20%| | | 0 |(Not specified)| 297 |Coupon | 30%| | | 1 |Beef 500g | 298 |Event ticket | 100%| | | 1 |Hall A, S ,K23 | 299 |Exchange ticket | 100%| | | 1 |ISBN:0071355014| 300 +----------------+-----+------+--------+----------+---------------+ 301 Table 1. Examples of vouchers and their properties 303 5. Syntax Overview and Examples 305 This section provides an overview and examples of Voucher 306 Component. The formal syntax and semantics are found in Sections 6 307 and 7. 309 Voucher Components are represented by the <Voucher> element which 310 has the following structure (where "?" denotes zero or one 311 occurrence): 313 <Voucher> 314 (Title) 315 (Description)? 316 (Provider) 317 (Issuer)? 318 (Holder)? 319 (Collector)? 320 (Value) 321 (Merchandise)? 322 (ValidPeriod)? 323 (Conditions)? 324 </Voucher> 326 An example of a Voucher Component is described below. This is an 327 example of a five dollar discount coupon for specific merchandize, 328 a book with ISBN number 0071355014. The coupon is valid from April 329 1st in 2001 to March 31st in 2002. To claim this offer, one voucher 330 must be spent. 332 <?xml version="1.0"?> 333 <Voucher xmlns="urn:ietf:params:xml:schema:vts-lang" 334 xmlns:vts="http://www.example.com/vts"> 335 <Title>IOTP Book Coupon 336 $5 off IOTP Book 337 338 VE2.31 339 340 341 342 1DA8DFCF95521014BBB7171B95545E8D61AE803F 343 344 345 346 347 348 349 350 352 353 354 355 The value of this coupon is subject to tax. 356 357 359 6. Syntax and Semantics 361 The general structure of an XML voucher is described in Component 362 Structure (section 4). This section details the Voucher Component 363 features. Features described in this section MUST be implemented 364 unless otherwise indicated. The syntax is defined via 365 [XML-Schema-1] [XML-Schema-2]. For clarity, unqualified elements in 366 schema definitions are in the XML schema namespace: 368 xmlns="http://www.w3.org/2001/XMLSchema" 370 References to XML Voucher schema defined herein use the prefix 371 "gvl" and are in the namespace: 373 xmlns:gvl="urn:ietf:params:xml:schema:vts-lang" 375 This namespace URI for elements defined by this document is a URN 376 [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] 377 and extended by [XML-Registry]. 379 This namespace is also used for unqualified elements in voucher 380 examples. 382 6.1 384 The element contains , <Provider>, and <Value> 385 elements and optionally contains <Description>, <Issuer>, <Holder>, 386 <Collector>, <ValidPeriod>, and <Condition> elements. These 387 sub-elements are defined in the following sections. 389 The <Voucher> element is defined by the following schema: 391 <element name="Voucher" type="gvl:VoucherType"/> 392 <complexType name="VoucherType"> 393 <sequence> 394 <element ref="gvl:Title"/> 395 <element ref="gvl:Description" minOccurs="0"/> 396 <element ref="gvl:Provider"/> 397 <element ref="gvl:Issuer" minOccurs="0"/> 398 <element ref="gvl:Holder" minOccurs="0"/> 399 <element ref="gvl:Collector" minOccurs="0"/> 400 <element ref="gvl:Value"/> 401 <element ref="gvl:Merchandise" minOccurs="0"/> 402 <element ref="gvl:ValidPeriod" minOccurs="0"/> 403 <element ref="gvl:Conditions" minOccurs="0"/> 404 </sequence> 405 </complexType> 407 6.2 <Title> 409 The <Title> element contains a simpletext title of the voucher. 410 This is mainly for listing the entities stored in a wallet system. 412 The <Title> element has no attribute. 414 The <Title> element is defined by the following schema: 416 <element name="Title" type="string"/> 418 6.3 <Description> 420 The <Description> element contains a simpletext description of the 421 voucher. This is mainly for listing the entities stored in a 422 wallet system. 424 The <Description> element has no attribute. 426 The <Description> element is defined by the following schema: 428 <element name="Description" type="string"/> 430 6.4 <Provider> 432 The <Provider> element may contain any elements that is used to 433 specify or restrict the VTS Provider of the voucher. The 434 sub-elements contained in this element depend on the implementation 435 of the VTS. 437 An implementation of a wallet system may use this information to 438 identify and/or authenticate the VTS Provider when the VTS plug-in is 439 registered (See Section 7 of [VTS-API]). These 440 implementation-specific elements of the VTS can be extended using 441 [XML-ns]. An example of such schema definition is described in 442 Section 8. 444 The <Provider> element has a string-type "name" attribute that is 445 used to specify the name of the VTS Provider. 447 The <Provider> element is defined by the following schema: 449 <element name="Provider" type="gvl:RoleType"/> 450 <complexType name="RoleType" mixed="true"> 451 <sequence> 452 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 453 </sequence> 454 <attribute name="name" type="string"/> 455 </complexType> 457 6.5 <Issuer> 458 The <Issuer> element may contain any element that is used to specify 459 or restrict the Issuer of the voucher. 461 The Issuer of the voucher is generally managed by the VTS [VTS-API]. 462 There is no need to specify the Issuer of the voucher using this 463 element if there are no restrictions on the Issuer. 464 An implementation of a VTS may use this element to describe the 465 authentication data and/or qualification information of the 466 Issuer. This implementation-specific information can be extended as 467 sub-elements using [XML-ns]. An example of such schema definition is 468 described in Section 8. 470 The <Issuer> element has a string-type "name" attribute that is used 471 to specify the name of the Issuer. 473 The <Issuer> element is defined by the following schema: 475 <element name="Issuer" type="gvl:RoleType"/> 476 The <RoleType> element type is defined in Section 6.4. 478 If the <Issuer> element is omitted, it MUST be interpreted that there 479 are no restrictions on the Issuer. 481 6.6 <Holder> 483 The <Holder> element may contain any elements that is used to specify 484 or restrict the Holder of the voucher. 486 The Holder of the voucher is generally managed by the VTS [VTS-API]. 487 There is no need to specify the Holder of the voucher using this 488 element if there are no restrictions on the Holder. 489 An implementation of a VTS may use this element to describe the 490 authentication data and/or qualification information of the 491 Holder. This implementation-specific information can be extended as 492 sub-elements using [XML-ns]. 494 The <Holder> element has a string-type "name" attribute that is used 495 to specify the name of the Holder. 497 The <Holder> element is defined by the following schema: 499 <element name="Holder" type="gvl:RoleType"/> 500 The <RoleType> element type is defined in Section 6.4. 502 If the <Holder> element is omitted, it MUST be interpreted that there 503 are no restrictions on the Holder. 505 6.7 <Collector> 507 The <Collector> element may contain any elements that is used to 508 specify or restrict the Collector of the voucher. 510 There is no need to specify the Collector of the voucher using this 511 element if there are no restrictions on the Collector. 512 An implementation of a VTS may use this element to describe the 513 authentication data and/or qualification information of the 514 Collector. This implementation-specific information can be extended 515 as sub-elements using [XML-ns]. 517 The <Collector> element has a string-type "name" attribute that is 518 used to specify the name of the Collector. 520 The <Collector> element is defined by the following schema: 522 <element name="Collector" type="gvl:RoleType"/> 523 The <RoleType> element type is defined in Section 6.4. 525 If the <Collector> element is omitted, it MUST be interpreted that 526 there are no restrictions on the Collector. 528 6.8 <Value> 530 The <Value> element optionally contains a <Fixed> or a <Ratio> 531 element but not both. These sub-elements are defined in the 532 following sections. 534 The <Value> element has a "type" attribute that is used to specify 535 the value process type. This attribute is provided to calculate the 536 amount paid when the vouchers are redeemed at Merchant site, etc. 538 The following identifiers are defined for the "type" attribute. 540 Exchange: Items specified in the <Merchandise> element can be 541 claimed in exchange for the voucher. If this type is selected, 542 neither <Ratio> nor <Fixed> element MUST be specified. Note that 543 this value process type has the same meaning as: 544 <Value type="discount"><Ratio percentage="100"/></Value> 546 Discount: Items specified in the <Merchandise> element can be 547 purchased at the discount price calculated by the <Ratio> or 548 <Fixed> element. 550 Monetary: Items specified in the <Merchandise> element can be 551 purchased using the value of the voucher. (Note: if the 552 <Merchandise> element is not specified, the voucher can be used 553 for any purchase.) If this type is selected, the <Fixed> element 554 MUST be specified. 556 The <Value> element also has a "spend" attribute that is used to 557 specify the number of vouchers to be redeemed for claiming the 558 goods, services, or monetary value specified. For example, if "n" 559 (>0) is specified, goods etc. can be claimed in exchange for "n 560 sheets of" vouchers. (Note: Multiple vouchers for the same Voucher 561 Component must exist in this case.) If "0" is specified, it can be 562 used repeatedly. 564 If the "spend" attribute is omitted or the whole element is omitted, 565 it MUST be interpreted that "1" is specified for the "spend" 566 attribute. 568 The <Value> element is defined by the following schema: 570 <element name="Value" type="gvl:ValueType"/> 571 <complexType name="ValueType"> 572 <sequence minOccurs="0"> 573 <choice> 574 <element name="Ratio" type="gvl:RatioValueType"/> 575 <element name="Fixed" type="gvl:FixedValueType"/> 576 </choice> 577 </sequence> 578 <attribute name="type" type="gvl:ValueProcessType" 579 use="required"/> 580 <attribute name="spend" type="nonNegativeInteger" 581 default="1"/> 582 </complexType> 584 The <ValueProcessType> element type is defined by the following 585 schema: 587 <simpleType name="ValueProcessType"> 588 <restriction base="string"> 589 <enumeration value="exchange"/> 590 <enumeration value="discount"/> 591 <enumeration value="monetary"/> 592 </restriction> 593 </simpleType> 595 6.8.1 <Ratio> 597 The <Ratio> element does not contain any contents. 599 The <Ratio> element has a "percentage" attribute that is used to 600 specify the discount ratio of the price of the corresponding 601 merchandize in percentage. 603 The <RatioValueType> element type is defined by the schema: 605 <complexType name="RatioValueType"> 606 <attribute name="percentage" use="required"> 607 <simpleType> 608 <restriction base="float"> 609 <maxInclusive value="100"/> 610 </restriction> 611 </simpleType> 612 </attribute> 613 </complexType> 615 6.8.2 <Fixed> 616 The <Fixed> element does not contain any contents. 618 The <Fixed> element has "currency" and "amount" attributes 619 and optionally a "decimalPower" attribute as follows: 621 Currency: Provides the unit of the monetary value in the three 622 letter ISO currency code [ISO4217]. For example, for US dollars 623 it is "USD". 625 Amount: Provides the amount of the monetary value per voucher. 627 DecimalPower: Provides the number of decimal digits from the 628 decimal point applied to the base for the "amount" attribute 629 above. If the "decimalPower" attribute is omitted, it MUST be 630 interpreted that "0" is specified for the "decimalPower" 631 attribute. 633 For example, with a dollar currency denominated in cents, "1" is 634 specifed for the "amount" attribute, and "-2" is specified for the 635 "decimalPower" attribute. Alternately, "0.01" is specified for 636 the "amount" attribute and the "decimalPower" attribute is omitted. 638 The <FixedValueType> type is defined by the following definition: 640 <complexType name="FixedValueType"> 641 <attribute name="currency" type="string" use="required"/> 642 <attribute name="amount" type="float" use="required"/> 643 <attribute name="decimalPower" type="short" default="0"/> 644 </complexType> 646 6.9 <Merchandise> 648 The <Merchandise> element may contain any elements used to specify or 649 restrict the goods or services rendered when the voucher is redeemed. 650 The sub-elements contained in this element are depending on the 651 application of the voucher and are left to the other domain-specific 652 specifications. Domain-specific elements can be extended as 653 sub-elements using [XML-ns]. 655 The <Merchandise> element does not have any attribute. 657 The <Merchandise> element is defined by the following schema: 659 <element name="Merchandise" type="gvl:MerchandiseType"/> 660 <complexType name="MerchandiseType" mixed="true"> 661 <sequence> 662 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 663 </sequence> 664 </complexType> 666 If the <Merchandise> element is omitted, it will be generally 667 interpreted that there is no restriction on the merchandise when 668 using the voucher. 670 6.10 <ValidPeriod> 672 The <VaridPeriod> element does not contain any contents. 674 The <ValidPeriod> element has dateTime-type "start" and "end" 675 attributes that are used to place limits on the validity of the 676 voucher. 678 The <ValidPeriod> element is defined by the following schema: 680 <element name="ValidPeriod" type="gvl:ValidPeriodType"/> 681 <complexType name="ValidPeriodType"> 682 <attribute name="start" type="dateTime"/> 683 <attribute name="end" type="dateTime"/> 684 </complexType> 686 If the "start" attribute is omitted, it MUST be interpreted that 687 the voucher is valid on any date up to the date (inclusive) 688 specified by the end attribute. If the "end" attribute is omitted, 689 it MUST be interpreted that the voucher is valid from the start 690 attribute with no expiry. If neither attribute is specified or the 691 whole element is omitted, it MUST be interpreted that the voucher 692 is valid at any time. 694 6.10 <Conditions> 696 The <Conditions> element may contain any element used to specify 697 any other restrictions or conditions applied that limit the use of 698 the voucher. The sub-elements contained in this element are 699 depending on the application of the voucher and are left to the 700 other domain-specific specifications. Domain-specific elements can 701 be extended as sub-elements using [XML-ns]. 703 The <Conditions> element does not have any attribute. 705 The <Conditions> element is defined by the following schema: 707 <element name="Conditions" type="gvl:ConditionsType"/> 708 <complexType name="ConditionsType" mixed="true"> 709 <sequence> 710 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 711 </sequence> 712 </complexType> 714 If the <Conditions> element is omitted, it will be generally 715 interpreted that there are no other restrictions or conditions on 716 using the voucher. 718 7. IANA Considerations 720 This document calls for IANA to register a new XML schema with the 721 URN. The registation form [XML-Registry] for this is below: 723 URI 724 urn:ietf:params:xml:schema:vts-lang 726 Registrant Contact 727 See the "Author's Address" section of this document. 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] D. Eastlake, "Electronic Commerce Modeling Language (ECML) 861 Version 2 Specification", draft-ietf-trade-ecml2-spec-06.txt, 862 November 2002. 864 [GVT] K. Fujimura, "Requirements and Design for Voucher Trading 865 System (VTS)", draft-ietf-trade-drt-requirements-04.txt, July 866 2002. (Approved by IESG, should be in RFC Editor queue.) 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-03.txt, August 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-04, June 2002. In RFC Editor 900 queue. 902 [XML-Schema-1] H. Thompson, D. Beech, M. Maloney, and 903 N. Mendelsohn, "XML Schema Part 1: Structures W3C Recommendation.", 904 <http://www.w3.org/TR/xmlschema-1/>, May 2001. 906 [XML-Schema-2] P. Biron and A Malhotra, "XML Schema Part 2: 907 Datatypes W3C Recommendation.", 908 <http://www.w3.org/TR/xmlschema-2/>, May 2001. 910 11. Author's Address 912 Ko Fujimura and Masayuki Terada 913 NTT Corporation 914 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 915 Phone: +81-(0)468-59-3814 916 Fax: +81-(0)468-59-8329 917 Email: fujimura@isl.ntt.co.jp, terada@isl.ntt.co.jp 919 Full Copyright Statement 921 Copyright (C) The Internet Society (2002). All Rights Reserved. 923 This document and translations of it may be copied and furnished to 924 others, and derivative works that comment on or otherwise explain it 925 or assist in its implementation may be prepared, copied, published 926 and distributed, in whole or in part, without restriction of any 927 kind, provided that the above copyright notice and this paragraph are 928 included on all such copies and derivative works. However, this 929 document itself may not be modified in any way, such as by removing 930 the copyright notice or references to the Internet Society or other 931 Internet organizations, except as needed for the purpose of 932 developing Internet standards in which case the procedures for 933 copyrights defined in the Internet Standards process must be 934 followed, or as required to translate it into languages other than 935 English. 937 The limited permissions granted above are perpetual and will not be 938 revoked by the Internet Society or its successors or assigns. 940 This document and the information contained herein is provided on an 941 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 942 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 943 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 944 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 945 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.