idnits 2.17.1 draft-ietf-trade-voucher-lang-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 958. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages 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 157 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 (January 2005) is 7038 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 118, but not defined == Unused Reference: 'RFC2119' is defined on line 879, 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) -- Unexpected draft version: The latest known version of draft-ietf-trade-voucher-vtsapi is -06, but you're referring to -07. Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Ko Fujimura 2 NTT 3 Masayuki Terada 4 NTT DoCoMo 5 Donald E. Eastlake 3rd 6 Motorola Laboratories 7 Expires July 2005 January 2005 9 XML Voucher: Generic Voucher Language 10 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Distribution of this document is unlimited. Comments should be sent 20 to the author or the IETF TRADE working group 21 . 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than a "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document specifies rules for defining voucher properties in XML 46 syntax. A voucher is a logical entity that represents a right to 47 claim goods or services. A voucher can be used to transfer a 48 wide-range of electronic-values, including coupons, tickets, loyalty 49 points, and gift certificates, which are often necessary to process 50 in the course of payment and/or delivery transactions. 52 Acknowledgements 54 The following persons, in alphabetic order, contributed substantially 55 to the material herein: 57 Ian Grigg 58 Renato Iannella 59 Yoshiaki Nakajima 61 Table of Contents 63 1. Introduction ...................................................3 64 2. Processing Model ...............................................3 65 3. Trust Model ....................................................4 66 4. Component Structure ............................................5 67 5. Syntax Overview and Examples ...................................7 68 6. Syntax and Semantics ...........................................8 69 6.1 ..................................................8 70 6.2 ....................................................9 71 6.3 <Description> ..............................................9 72 6.4 <Provider> .................................................9 73 6.5 <Issuer> ...................................................9 74 6.6 <Holder> ..................................................10 75 6.7 <Collector> ...............................................10 76 6.8 <Value> ...................................................11 77 6.8.1 <Ratio> .................................................12 78 6.8.2 <Fixed> .................................................12 79 6.9 <Merchandise> .............................................13 80 6.10 <ValidPeriod> ............................................14 81 6.11 <Conditions> .............................................14 82 7. IANA Considerations ...........................................14 83 8. VTS Schema Example ............................................17 84 9. Security Considerations .......................................17 86 Normative References .............................................17 87 Informational References .........................................18 88 Author's Address .................................................19 89 Copyright and Disclaimer..........................................19 90 File name and Expiration..........................................19 92 1. Introduction 94 This document, XML Voucher, specifies rules for defining voucher 95 properties in XML syntax. The motivation and background of the 96 specification are described in [VTS]. 98 A voucher is a logical entity that represents a certain right and 99 is logically managed by the Voucher Trading System (VTS). A voucher 100 is generated by the issuer, traded among users, and finally 101 collected by the collector using VTS. 103 This document defines the syntax and semantics of Voucher 104 Component, which defines voucher meaning and processing rules in 105 XML syntax [XML]. A Voucher Component define the properties that 106 must be satisfied to allow the voucher to be processed by VTS or 107 other trading systems, e.g., wallet or merchant system. VTS 108 definitions and models are also defined in [VTS]. 110 Note: This document uses "voucher" as an "instance of voucher" 111 whose meaning is defined by Voucher Component. In other words, a 112 Voucher Component is NOT a voucher and multiple vouchers can be 113 issued and managed by the VTS using the same Voucher Component. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 117 this document are to be interpreted as described in [RFC 2119] 119 2. Processing Model 121 There are several ways of implementing VTS and technologies are 122 continually changing. For discount coupons or event tickets, for 123 example, the smart-card-based offline VTS is often preferred, 124 whereas for bonds or securities, the centralized online VTS is 125 preferred. It is impractical to define standard protocols for 126 issuing, transferring, or redeeming vouchers at this moment. 128 To provide implementation flexibility, this document assumes a 129 modular wallet architecture that allows multiple VTS to be added as 130 plug-ins. In this architecture, instead of specifying a standard 131 voucher transfer protocol, two specifications, i.e., Voucher 132 Component and VTS-API specifications, are standardized (Figure 1). 134 After sender and receiver agree on what vouchers are to be traded 135 and which VTS is to be used, the issuing system or wallet system 136 requests the corresponding VTS plug-in to permit the issue, 137 transfer, or redeem transactions to be performed via the VTS 138 API. The VTS then rewrites the ownership of the vouchers using the 139 VTS-specific protocol. Finally, a completion event is sent to the 140 wallet systems or issuing/collecting systems. 142 This document describes the Voucher Component specification. The 143 VTS-API specification is defined in [VTS-API]. 145 Sender wallet/Issuing system Receiver wallet/Collecting system 146 +---------------------------+ +---------------------------+ 147 | | | | 148 | | Voucher Component | | 149 | | (Specifies VTS Provider and Promise) | | 150 | |-------------------------------------------------------->| | 151 | | | | | | 152 | | Intention to receive and payment (option) | | 153 | |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | | 154 | | | | | | 155 | | | | | | 156 | | Issue/transfer/ VTS | | VTS Register | | 157 | | redeem request plug-in | plug-in Listener(*1)| | 158 | |------------------>| | | |<------------------| | 159 | | (VTS-API) |<- - - - - - - ->| (VTS-API) | | 160 | | | VTS-specific | | | 161 | | | protocol if VTS | | | 162 | | | is distributed | | | 163 | | Result |<- - - - - - - ->| Notify(*2) | | 164 | |<------------------| | | |------------------>| | 165 +---------------------------+ +---------------------------+ 166 (*1) Registration is optional. Note also that the VTS plug-ins are 167 usually pre-registered when the wallet or collecting system 168 is started. 169 (*2) If a listener is registered. 171 Figure 1. Wallet architecture with VTS plug-ins 173 3. Trust Model 175 A voucher is trusted if the Issuer and VTS Provider are trusted, 176 since the Issuer is responsible for the contents of the voucher and 177 the VTS Provider is responsible for preventing ownership from being 178 assigned to multiple users. 180 The trust level required for Issuer and VTS Provider depends on the 181 type (or Promise) of the voucher. To provide the information needed 182 for verification, the conditions of Issuer and VTS Provider are 183 specified in the Voucher Component, and given as input to the 184 verifier, e.g., wallet system or other software. The trust of a 185 voucher is thus verified through the Voucher Component. This model 186 enables trading partners to verify their trust in the voucher 187 regardless of their trust in the partners. 189 This document assumes that the Voucher Component is the root of 190 trust. If a malicious user could alter the Voucher Component, a 191 forged voucher, could be verified as valid. 193 When a Voucher Component is delivered from the trusted VTS 194 Provider, Issuer or trusted third party, a secure communication 195 channel, e.g., [TLS], [IPSEC], or object security, e.g.,[XMLDSIG] 196 should be used to prevent from being altered during the delivery. 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 250 Provides restrictions on the Collector of the voucher. 252 Value Component 254 Provides the value of each voucher. There are two types of 255 values, i.e., fixed and ratio values. For a fixed value, the 256 currency and the figure is specified. For a ratio value, the 257 discount ratio of the corresponding merchandize is specified. 259 The Value Component also indicates the number of vouchers to be 260 redeemed for claiming the merchandise or monetary value specified 261 in Merchandise Component or Value Component. If "n"(>0) is 262 specified, the merchandize or monetary value can be claimed in 263 exchange for "n sheets of" vouchers. If "0" is specified, it 264 can be used repeatedly. 266 Merchandise Component 268 Provides restrictions on the object to be claimed. 269 Domain-specific meaning of the voucher, e.g., reference number of 270 the merchandize or seat number for an event ticket, is specified 271 to identify the merchandize rendered when the voucher is 272 redeemed. 274 ValidPeriod Component 276 Provides restrictions on the validity period of the voucher, 277 i.e., start date and end date. 279 Condition Component 281 Provides any other applicable restrictions. This is intended to 282 cover contracts between the issuer and holder of the 283 voucher in natural language form. 285 Using the above Components, semantics for diverse types of vouchers 286 can be defined as shown in Table 1. 288 +----------------+--------------------------------+---------------+ 289 | | Value | Restrictions | 290 | +-----+---------------+----------+---------------+ 291 | Examples |Ratio| Fixed |Number | Merchandise | 292 | | +------+--------+Needed for| | 293 | | |Amount|Currency|redemption| | 294 +----------------+-----+------+--------+----------+---------------+ 295 |Gift certificate| | 25 | USD | 1 |(Not specified)| 296 |Loyalty point | | 1 | AUD | 10 |(Not specified)| 297 |Member card | 20%| | | 0 |(Not specified)| 298 |Coupon | 30%| | | 1 |Beef 500g | 299 |Event ticket | 100%| | | 1 |Hall A, S ,K23 | 300 |Exchange ticket | 100%| | | 1 |ISBN:0071355014| 301 +----------------+-----+------+--------+----------+---------------+ 302 Table 1. Examples of vouchers and their properties 304 5. Syntax Overview and Examples 306 This section provides an overview and examples of Voucher 307 Component. The formal syntax and semantics are found in Sections 6 308 and 7. 310 Voucher Components are represented by the <Voucher> element which 311 has the following structure (where "?" denotes zero or one 312 occurrence): 314 <Voucher> 315 (Title) 316 (Description)? 317 (Provider) 318 (Issuer)? 319 (Holder)? 320 (Collector)? 321 (Value) 322 (Merchandise)? 323 (ValidPeriod)? 324 (Conditions)? 325 </Voucher> 327 An example of a Voucher Component is described below. This is an 328 example of a five dollar discount coupon for specific merchandize, 329 a book with ISBN number 0071355014. The coupon is valid from April 330 1st in 2001 to March 31st in 2002. To claim this offer, one voucher 331 must be spent. 333 <?xml version="1.0" encoding="UTF-8"?> 334 <Voucher xmlns="urn:ietf:params:xml:ns:vts-lang" 335 xmlns:vts="http://www.example.com/vts"> 336 <Title>IOTP Book Coupon 337 $5 off IOTP Book 338 339 VE2.31 340 341 342 343 1DA8DFCF95521014BBB7171B95545E8D61AE803F 344 345 346 347 348 349 350 351 353 354 355 356 The value of this coupon is subject to tax. 357 358 360 6. Syntax and Semantics 362 The general structure of an XML Voucher Component is described in 363 Section 4 above. This section details the Voucher Component 364 features. Features described in this section MUST be implemented 365 unless otherwise indicated. The syntax is defined via 366 [XML-Schema-1] [XML-Schema-2]. For clarity, unqualified elements in 367 schema definitions are in the XML schema namespace: 369 xmlns="http://www.w3.org/2001/XMLSchema" 371 References to XML Voucher schema defined herein use the prefix 372 "gvl" and are in the namespace: 374 xmlns:gvl="urn:ietf:params:xml:ns:vts-lang" 376 This namespace URI for elements defined by this document is a URN 377 [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] 378 and extended by [XML-Registry]. 380 This namespace is also used for unqualified elements in voucher 381 examples. 383 6.1 385 The element contains , <Provider>, and <Value> 386 elements and optionally contains <Description>, <Issuer>, <Holder>, 387 <Collector>, <ValidPeriod>, and <Condition> elements. These 388 sub-elements are defined in the following sections. 390 The <Voucher> element is defined by the following schema: 392 <element name="Voucher" type="gvl:VoucherType"/> 393 <complexType name="VoucherType"> 394 <sequence> 395 <element ref="gvl:Title"/> 396 <element ref="gvl:Description" minOccurs="0"/> 397 <element ref="gvl:Provider"/> 398 <element ref="gvl:Issuer" minOccurs="0"/> 399 <element ref="gvl:Holder" minOccurs="0"/> 400 <element ref="gvl:Collector" minOccurs="0"/> 401 <element ref="gvl:Value"/> 402 <element ref="gvl:Merchandise" minOccurs="0"/> 403 <element ref="gvl:ValidPeriod" minOccurs="0"/> 404 <element ref="gvl:Conditions" minOccurs="0"/> 405 </sequence> 406 </complexType> 408 6.2 <Title> 410 The <Title> element contains a simpletext title of the voucher. 411 This is mainly for listing the entities stored in a wallet system. 413 The <Title> element has no attribute. 415 The <Title> element is defined by the following schema: 417 <element name="Title" type="string"/> 419 6.3 <Description> 421 The <Description> element contains a simpletext description of the 422 voucher. This is mainly for listing the entities stored in a 423 wallet system. 425 The <Description> element has no attribute. 427 The <Description> element is defined by the following schema: 429 <element name="Description" type="string"/> 431 6.4 <Provider> 433 The <Provider> element may contain any elements that is used to 434 specify or restrict the VTS Provider of the voucher. The 435 sub-elements contained in this element depend on the implementation 436 of the VTS. 438 An implementation of a wallet system may use this information to 439 identify and/or authenticate the VTS Provider when the VTS plug-in is 440 registered (See Section 7 of [VTS-API]). These 441 implementation-specific elements of the VTS can be extended using 442 [XML-ns]. An example of such schema definition is described in 443 Section 8. 445 The <Provider> element has a string-type "name" attribute that is 446 used to specify the name of the VTS Provider. 448 The <Provider> element is defined by the following schema: 450 <element name="Provider" type="gvl:RoleType"/> 451 <complexType name="RoleType" mixed="true"> 452 <sequence> 453 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 454 </sequence> 455 <attribute name="name" type="string"/> 456 </complexType> 458 6.5 <Issuer> 459 The <Issuer> element may contain any element that is used to specify 460 or restrict the Issuer of the voucher. 462 The Issuer of the voucher is generally managed by the VTS [VTS-API]. 463 There is no need to specify the Issuer of the voucher using this 464 element if there are no restrictions on the Issuer. 465 An implementation of a VTS may use this element to describe the 466 authentication data and/or qualification information of the 467 Issuer. This implementation-specific information can be extended as 468 sub-elements using [XML-ns]. An example of such schema definition is 469 described in Section 8. 471 The <Issuer> element has a string-type "name" attribute that is used 472 to specify the name of the Issuer. 474 The <Issuer> element is defined by the following schema: 476 <element name="Issuer" type="gvl:RoleType"/> 477 The <RoleType> element type is defined in Section 6.4. 479 If the <Issuer> element is omitted, it MUST be interpreted that there 480 are no restrictions on the Issuer. 482 6.6 <Holder> 484 The <Holder> element may contain any elements that is used to specify 485 or restrict the Holder of the voucher. 487 The Holder of the voucher is generally managed by the VTS [VTS-API]. 488 There is no need to specify the Holder of the voucher using this 489 element if there are no restrictions on the Holder. 490 An implementation of a VTS may use this element to describe the 491 authentication data and/or qualification information of the 492 Holder. This implementation-specific information can be extended as 493 sub-elements using [XML-ns]. 495 The <Holder> element has a string-type "name" attribute that is used 496 to specify the name of the Holder. 498 The <Holder> element is defined by the following schema: 500 <element name="Holder" type="gvl:RoleType"/> 501 The <RoleType> element type is defined in Section 6.4. 503 If the <Holder> element is omitted, it MUST be interpreted that there 504 are no restrictions on the Holder. 506 6.7 <Collector> 508 The <Collector> element may contain any elements that is used to 509 specify or restrict the Collector of the voucher. 511 There is no need to specify the Collector of the voucher using this 512 element if there are no restrictions on the Collector. 513 An implementation of a VTS may use this element to describe the 514 authentication data and/or qualification information of the 515 Collector. This implementation-specific information can be extended 516 as sub-elements using [XML-ns]. 518 The <Collector> element has a string-type "name" attribute that is 519 used to specify the name of the Collector. 521 The <Collector> element is defined by the following schema: 523 <element name="Collector" type="gvl:RoleType"/> 524 The <RoleType> element type is defined in Section 6.4. 526 If the <Collector> element is omitted, it MUST be interpreted that 527 there are no restrictions on the Collector. 529 6.8 <Value> 531 The <Value> element optionally contains a <Fixed> or a <Ratio> 532 element but not both. These sub-elements are defined in the 533 following sections. 535 The <Value> element has a "type" attribute that is used to specify 536 the value process type. This attribute is provided to calculate the 537 amount paid when the vouchers are redeemed at Merchant site, etc. 539 The following identifiers are defined for the "type" attribute. 541 Exchange: Items specified in the <Merchandise> element can be 542 claimed in exchange for the voucher. If this type is selected, 543 neither <Ratio> nor <Fixed> element MUST be specified. Note that 544 this value process type has the same meaning as: 545 <Value type="discount"><Ratio percentage="100"/></Value> 547 Discount: Items specified in the <Merchandise> element can be 548 purchased at the discount price calculated by the <Ratio> or 549 <Fixed> element. 551 Monetary: Items specified in the <Merchandise> element can be 552 purchased using the value of the voucher. (Note: if the 553 <Merchandise> element is not specified, the voucher can be used 554 for any purchase.) If this type is selected, the <Fixed> element 555 MUST be specified. 557 The <Value> element also has a "spend" attribute that is used to 558 specify the number of vouchers to be redeemed for claiming the 559 goods, services, or monetary value specified. For example, if "n" 560 (>0) is specified, goods etc. can be claimed in exchange for "n 561 sheets of" vouchers. (Note: Multiple vouchers for the same Voucher 562 Component must exist in this case.) If "0" is specified, it can be 563 used repeatedly. 565 If the "spend" attribute is omitted or the whole element is omitted, 566 it MUST be interpreted that "1" is specified for the "spend" 567 attribute. 569 The <Value> element is defined by the following schema: 571 <element name="Value" type="gvl:ValueType"/> 572 <complexType name="ValueType"> 573 <sequence minOccurs="0"> 574 <choice> 575 <element name="Ratio" type="gvl:RatioValueType"/> 576 <element name="Fixed" type="gvl:FixedValueType"/> 577 </choice> 578 </sequence> 579 <attribute name="type" type="gvl:ValueProcessType" 580 use="required"/> 581 <attribute name="spend" type="nonNegativeInteger" 582 default="1"/> 583 </complexType> 585 The <ValueProcessType> element type is defined by the following 586 schema: 588 <simpleType name="ValueProcessType"> 589 <restriction base="string"> 590 <enumeration value="exchange"/> 591 <enumeration value="discount"/> 592 <enumeration value="monetary"/> 593 </restriction> 594 </simpleType> 596 6.8.1 <Ratio> 598 The <Ratio> element does not contain any contents. 600 The <Ratio> element has a "percentage" attribute that is used to 601 specify the discount ratio of the price of the corresponding 602 merchandize in percentage. 604 The <RatioValueType> element type is defined by the schema: 606 <complexType name="RatioValueType"> 607 <attribute name="percentage" use="required"> 608 <simpleType> 609 <restriction base="float"> 610 <maxInclusive value="100"/> 611 </restriction> 612 </simpleType> 613 </attribute> 614 </complexType> 616 6.8.2 <Fixed> 617 The <Fixed> element does not contain any contents. 619 The <Fixed> element has "currency" and "amount" attributes 620 and optionally a "decimalPower" attribute as follows: 622 Currency: Provides the unit of the monetary value in the three 623 letter ISO currency code [ISO4217]. For example, for US dollars 624 it is "USD". 626 Amount: Provides the amount of the monetary value per voucher. 628 DecimalPower: Provides the number of decimal digits from the 629 decimal point applied to the base for the "amount" attribute 630 above. If the "decimalPower" attribute is omitted, it MUST be 631 interpreted that "0" is specified for the "decimalPower" 632 attribute. 634 For example, with a dollar currency denominated in cents, "1" is 635 specifed for the "amount" attribute, and "-2" is specified for the 636 "decimalPower" attribute. Alternately, "0.01" is specified for 637 the "amount" attribute and the "decimalPower" attribute is omitted. 639 The <FixedValueType> type is defined by the following definition: 641 <complexType name="FixedValueType"> 642 <attribute name="currency" type="string" use="required"/> 643 <attribute name="amount" type="float" use="required"/> 644 <attribute name="decimalPower" type="short" default="0"/> 645 </complexType> 647 6.9 <Merchandise> 649 The <Merchandise> element may contain any elements used to specify or 650 restrict the goods or services rendered when the voucher is redeemed. 651 The sub-elements contained in this element are depending on the 652 application of the voucher and are left to the other domain-specific 653 specifications. Domain-specific elements can be extended as 654 sub-elements using [XML-ns]. 656 This element is intended to be interpreted by a collecting system. 657 An implementation of a wallet system does not have to use this 658 element. Any restrictions applied should also be described in the 659 <Description> element or the <Conditions> elements in natural 660 language form to enable users to check the restrictions. 662 The <Merchandise> element does not have any attribute. 664 The <Merchandise> element is defined by the following schema: 666 <element name="Merchandise" type="gvl:MerchandiseType"/> 667 <complexType name="MerchandiseType" mixed="true"> 668 <sequence> 669 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 671 </sequence> 672 </complexType> 674 6.10 <ValidPeriod> 676 The <VaridPeriod> element does not contain any contents. 678 The <ValidPeriod> element has dateTime-type "start" and "end" 679 attributes that are used to place limits on the validity of the 680 voucher. 682 The <ValidPeriod> element is defined by the following schema: 684 <element name="ValidPeriod" type="gvl:ValidPeriodType"/> 685 <complexType name="ValidPeriodType"> 686 <attribute name="start" type="dateTime"/> 687 <attribute name="end" type="dateTime"/> 688 </complexType> 690 If the "start" attribute is omitted, it MUST be interpreted that 691 the voucher is valid on any date up to the date (inclusive) 692 specified by the end attribute. If the "end" attribute is omitted, 693 it MUST be interpreted that the voucher is valid from the start 694 attribute with no expiry. If neither attribute is specified or the 695 whole element is omitted, it MUST be interpreted that the voucher 696 is valid at any time. 698 6.11 <Conditions> 700 The <Conditions> element contains any other restrictions or 701 conditions applied. This is intended to cover contracts between the 702 issuer and holder of the voucher in natural language form. 704 An implementation of a wallet system SHOULD provide a means of 705 displaying the text in this element. 707 The <Conditions> element has no attribute. 709 The <Conditions> element is defined by the following schema: 711 <element name="Conditions" type="string"/> 713 7. IANA Considerations 715 This document uses URNs to describe XML namespaces and XML schemas 716 conforming to a registry mechanism described in [XML-Registry]. 717 Two URI assignments are requested. 719 Registration request for the vts-lang namespace: 721 URI: urn:ietf:params:xml:ns:vts-lang 723 Registrant Contact: See the "Author's Address" section of this 724 document. 726 XML: None. Namespace URIs do not represent an XML specification. 728 Registration request for the vts-lang XML schema: 730 URI: urn:ietf:params:xml:schema:vts-lang 732 Registrant Contact: See the "Author's Address" section of this 733 document. 735 XML: 736 BEGIN 737 <?xml version="1.0" encoding="UTF-8"?> 739 <schema 740 targetNamespace="urn:ietf:params:xml:ns:vts-lang" 741 xmlns:gvl="urn:ietf:params:xml:ns:vts-lang" 742 xmlns="http://www.w3.org/2001/XMLSchema" 743 elementFormDefault="qualified"> 745 <element name="Voucher" type="gvl:VoucherType"/> 746 <complexType name="VoucherType"> 747 <sequence> 748 <element ref="gvl:Title"/> 749 <element ref="gvl:Description" minOccurs="0"/> 750 <element ref="gvl:Provider"/> 751 <element ref="gvl:Issuer" minOccurs="0"/> 752 <element ref="gvl:Holder" minOccurs="0"/> 753 <element ref="gvl:Collector" minOccurs="0"/> 754 <element ref="gvl:Value"/> 755 <element ref="gvl:Merchandise" minOccurs="0"/> 756 <element ref="gvl:ValidPeriod" minOccurs="0"/> 757 <element ref="gvl:Conditions" minOccurs="0"/> 758 </sequence> 759 </complexType> 761 <element name="Title" type="string"/> 763 <element name="Description" type="string"/> 765 <element name="Provider" type="gvl:RoleType"/> 766 <element name="Issuer" type="gvl:RoleType"/> 767 <element name="Holder" type="gvl:RoleType"/> 768 <element name="Collector" type="gvl:RoleType"/> 769 <complexType name="RoleType" mixed="true"> 770 <sequence> 771 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 772 </sequence> 773 <attribute name="name" type="string"/> 774 </complexType> 776 <element name="Value" type="gvl:ValueType"/> 777 <complexType name="ValueType"> 778 <sequence minOccurs="0"> 779 <choice> 780 <element name="Ratio" type="gvl:RatioValueType"/> 781 <element name="Fixed" type="gvl:FixedValueType"/> 782 </choice> 783 </sequence> 784 <attribute name="type" type="gvl:ValueProcessType" 785 use="required"/> 786 <attribute name="spend" type="nonNegativeInteger" 787 default="1"/> 788 </complexType> 790 <simpleType name="ValueProcessType"> 791 <restriction base="string"> 792 <enumeration value="exchange"/> 793 <enumeration value="discount"/> 794 <enumeration value="monetary"/> 795 </restriction> 796 </simpleType> 798 <complexType name="RatioValueType"> 799 <attribute name="percentage" use="required"> 800 <simpleType> 801 <restriction base="float"> 802 <maxInclusive value="100"/> 803 </restriction> 804 </simpleType> 805 </attribute> 806 </complexType> 808 <complexType name="FixedValueType"> 809 <attribute name="currency" type="string" use="required"/> 810 <attribute name="amount" type="float" use="required"/> 811 <attribute name="decimalPower" type="short" default="0"/> 812 </complexType> 814 <element name="Merchandise" type="gvl:MerchandiseType"/> 815 <complexType name="MerchandiseType" mixed="true"> 816 <sequence> 817 <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/> 818 </sequence> 819 </complexType> 821 <element name="ValidPeriod" type="gvl:ValidPeriodType"/> 822 <complexType name="ValidPeriodType"> 823 <attribute name="start" type="dateTime"/> 824 <attribute name="end" type="dateTime"/> 825 </complexType> 827 <element name="Conditions" type="string"/> 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 The VTS must provide a means of preventing forgery, alteration, 856 duplicate-redemption, reproduction of a voucher, and non-repudiation 857 of transactions as described in Section 3.2 of [VTS]. This will 858 commonly require the presence of a unique serial number or the like 859 in each Voucher instance, usually outside the Voucher Component. 860 These security requirements, however, mainly follow the VTS plug-ins 861 and their protocols. This document assumes that the VTS plug-ins are 862 trusted and installed by some means, e.g., manually checked like 863 other download applications. 865 The Voucher Component, however, defines restrictions on VTS Provider 866 (or VTS plug-in), and, if this information is altered, incorrect VTS 867 plug-ins not accepted by the issuer could be used, allowing a forged 868 voucher to be verified as if it were valid. To prevent this 869 situation, the Voucher Component should be stored and acquired 870 securely, e.g., downloaded from a trusted party using a secure 871 communication channel, such as [TLS], or [IPSEC], or secured by the 872 digital signature of a trusted party [XMLDSIG]. 874 Normative References 876 [ISO4217] "Codes for the representation of currencies and funds", 877 ISO 4217, 1995. 879 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 880 Requirement Levels", BCP 14, RFC 2119, March 1997. 882 [URN] R. Moats, "URN Syntax", RFC2141, May 1997. 884 [URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents", 885 RFC2648, August 1999. 887 [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A 888 W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000. 890 [XML-ns] "Namespaces in XML", A W3C Recommendation, 891 <http://www.w3.org/TR/REC-xml-names>, January 1999. 893 [XML-Registry] M. Mealling, "The IETF XML Registry", RFC3688 894 January 2004. 896 [XML-Schema-1] H. Thompson, D. Beech, M. Maloney, and 897 N. Mendelsohn, "XML Schema Part 1: Structures W3C Recommendation.", 898 <http://www.w3.org/TR/xmlschema-1/>, May 2001. 900 [XML-Schema-2] P. Biron and A Malhotra, "XML Schema Part 2: 901 Datatypes W3C Recommendation.", 902 <http://www.w3.org/TR/xmlschema-2/>, May 2001. 904 Informational References 906 [VTS] K. Fujimura, D Eastlake, "Requirements and Design for Voucher 907 Trading System (VTS)", RFC3506, March 2003. 909 [IPSEC] R. Thayer, N. Doraswamy, and R. Glenn, "IP Security Document 910 Roadmap", RFC2411, November 1998 912 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, 913 January 1999. 915 [VTS-API] M. Terada and K. Fujimura, "Voucher Trading System 916 Application Programming Interface (VTS-API)", 917 draft-ietf-trade-voucher-vtsapi-07.txt, January 2005. 919 [XMLDSIG] D. Eastlake, J. Reagle, and D. Solo, "XML-Signature 920 Syntax and Processing", RFC3275, March 2002. 922 Author's Address 924 Ko Fujimura 925 NTT Corporation 926 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 927 Phone: +81-(0)46-859-3053 928 Fax: +81-(0)46-855-1730 929 Email: fujimura.ko@lab.ntt.co.jp 931 Masayuki Terada 932 NTT DoCoMo, Inc. 933 3-5 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-8536 JAPAN 934 Phone: +81-(0)46-840-3809 935 Fax: +81-(0)46-840-3705 936 Email: te@rex.yrp.nttdocomo.co.jp 938 Donald E. Eastlake 3rd 939 Motorola Laboratories 940 155 Beaver Street 941 Milford, MA 01757 USA 942 Phone: 1-508-786-7554 (work) 943 1-508-634-2066 (home) 944 EMail: Donald.Eastlake@motorola.com 946 Copyright and Disclaimer 948 Copyright (C) The Internet Society 2005. This document is subject to 949 the rights, licenses and restrictions contained in BCP 78 and except 950 as set forth therein, the authors retain all their rights. 952 This document and the information contained herein are provided on an 953 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 954 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 955 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 956 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 957 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 958 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 960 File name and Expiration 962 This file is draft-ietf-trade-voucher-lang-07.txt. 964 It expires July 2005.