RFC3506 日本語訳
3506 Requirements and Design for Voucher Trading System (VTS). K.Fujimura, D. Eastlake. March 2003. (Format: TXT=30945 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Fujimura
Request for Comments: 3506 NTT
Category: Informational D. Eastlake
Motorola
March 2003
コメントを求めるワーキンググループK.藤村の要求をネットワークでつないでください: 3506年のNTTカテゴリ: 2003年の情報のD.イーストレークのモトローラの行進
Requirements and Design for Voucher Trading System (VTS)
バウチャー取引システムのための要件とデザイン(VTS)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. These activities can be generalized using the concept of a "voucher", which is a digital representation of the right to claim goods or services. This document presents a Voucher Trading System (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described.
ロイヤルティポイントを掛けて、電子クーポンか商品券を集めるのは、取引を購入して、交えることにおいて一般的な機能です。 「バウチャー」の概念(商品かサービスを要求する権利のディジタル表現である)を使用することでこれらの活動を一般化できます。 このドキュメントはバウチャーをしっかりと循環させるVoucher Trading System(VTS)とその用語を提示します。 それはVTSとGeneric Voucher Language(GVL)のための設計原理と要件をリストアップします、どのさまざまのタイプのバウチャーについて説明できるかで。
Conventions used in this document
本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Table of Contents
目次
1. Background ....................................................2
2. Terminology and Model .........................................3
2.1 Voucher ...................................................3
2.2 Participants ..............................................3
2.3 Voucher Trading System (VTS) ..............................4
3. VTS Requirements ..............................................5
3.1 Capability to handle diversity ............................6
3.2 Ensuring security .........................................6
3.3 Ensuring practicality .....................................7
1. バックグラウンド…2 2. 用語とモデル…3 2.1バウチャー…3 2.2人の関係者…3 2.3 バウチャー取引システム(VTS)…4 3. VTS要件…5 多様性を扱う3.1能力…6 3.2 セキュリティを確実にします…6 3.3 実用性を確実にします…7
Fujimura & Eastlake Informational [Page 1] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[1ページ]のRFC3506バウチャー取引システム(VTS)行進
4. Scope of VTS Specifications ...................................7
4.1 Voucher Trading Protocol ..................................7
4.2 VTS-API ...................................................8
4.3 Generic Voucher Language ..................................8
5. GVL Requirements ..............................................8
5.1 Semantics .................................................8
5.2 Syntax ....................................................9
5.3 Security .................................................10
5.4 Efficiency ...............................................10
5.5 Coordination .............................................10
5.6 Example of GVL ...........................................10
6. Application Scenarios ........................................11
7. Q & A ........................................................13
8. Security Considerations ......................................13
9. Acknowledgments ..............................................13
10. References ...................................................13
11. Authors' Addresses ...........................................14
12. Full Copyright Statement......................................15
4. VTS仕様の範囲…7 4.1 バウチャーの取り引きプロトコル…7 4.2VTS-API…8 4.3 一般的なバウチャー言語…8 5. GVL要件…8 5.1意味論…8 5.2構文…9 5.3セキュリティ…10 5.4効率…10 5.5コーディネート…10 GVLに関する5.6の例…10 6. アプリケーションシナリオ…11 7. Q&A…13 8. セキュリティ問題…13 9. 承認…13 10. 参照…13 11. 作者のアドレス…14 12. 完全な著作権宣言文…15
1. Background
1. バックグラウンド
It is often necessary to credit loyalty points, collect digital coupons or gift certificates, etc, to complete purchases or other trading transactions in the real world. The importance of these activities is also being recognized in Internet Commerce. If a different issuing or collecting system to handle such points or coupons must be developed for each individual application, the implementation cost will be excessive, inhibiting the use of such mechanisms in electronic commerce. Consumers may also be forced to install a number of software modules to handle these points or coupons.
それが、本当の世界で購買か他の取り引き取引を完了するのにしばしばクレジットロイヤルティポイントや料金先方払いの電子クーポンや商品券などに必要です。 また、これらの活動の重要性はインターネットCommerceで認識されています。 それぞれの個々のアプリケーションのためにそのようなポイントかクーポンを扱う異なった発行か収集システムを開発しなければならないと、実現費用は過度になるでしょう、電子商取引におけるそのようなメカニズムの使用を抑制して。 また、消費者は、これらのポイントかクーポンを扱うためにやむを得ず多くのソフトウェア・モジュールをインストールするかもしれません。
A voucher is a digital representation of the right to claim services or goods. Using vouchers, a wide-range of electronic-values, including points or coupons, can be handled in a uniform manner with one trading software module.
バウチャーはサービスか商品を要求する権利のディジタル表現です。 バウチャーを使用して、一定の方法で1つの取り引きソフトウェア・モジュールでポイントかクーポンを含む広い範囲の電子値は扱うことができます。
This document presents the terminology and model for a Voucher Trading System (VTS) that circulates vouchers securely; it also lists design principles and requirements for a VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described.
このドキュメントはバウチャーをしっかりと循環させるVoucher Trading System(VTS)のために用語とモデルを提示します。 また、それはVTSとGeneric Voucher Language(GVL)のための設計原理と要件をリストアップします、どのさまざまのタイプのバウチャーについて説明できるかで。
Fujimura & Eastlake Informational [Page 2] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[2ページ]のRFC3506バウチャー取引システム(VTS)行進
2. Terminology and Model
2. 用語とモデル
2.1 Voucher
2.1 バウチャー
A voucher is a digital representation of the right to claim goods or services. To clarify the difference between vouchers and electronic money/digital certificates, we introduce a formal definition of vouchers in this document.
バウチャーは商品かサービスを要求する権利のディジタル表現です。 バウチャーと電子マネー/デジタルの証明書の違いをはっきりさせるために、私たちは本書ではバウチャーの公式の定義を導入します。
Let I be a voucher issuer, H be a voucher holder, P be the
issuer's promise to the voucher holder. A voucher is defined as
the 3-tuple of <I, P, H>.
P、バウチャー所有者になってください。H、Iがバウチャー発行人であることをさせてください、バウチャー所有者への発行人の約束になってください。 バウチャーは<I、P、H>の3-tupleと定義されます。
Examples of P are as follows:
Pの例は以下の通りです:
o Two loyalty points are added to the card per purchase. If you
collect 50 points, you'll get one item free. (Loyalty points)
o 2つのロイヤルティポイントが1購買あたりのカードに加えられます。 50ポイントを集めると、あなたは1個の商品を自由にするでしょう。 (ロイヤルティポイント)
o Take 10% off your total purchase by presenting this card.
(Membership card)
o あなたの合計からの%がこのカードを贈ることによって購入するTake 10。 (会員証)
o Take 50% off your total purchase with this coupon. The purchase
transaction uses up the coupon. (Coupon)
o このクーポンによる総購買を50%取り去ってください。 購買取引はクーポンを使いきります。 (クーポン)
o The bearer can access "http://..." for one month free. (Free
ticket for sales promotion)
o 運搬人はそうすることができます。アクセス" http://.. " 自由な1カ月。 (販売促進の無料のチケット)
o The bearer can exchange this ticket for the ordered clothes.
(Exchange ticket or Delivery note)
o 運搬人は命令された衣服のこのチケットを交換できます。 (商品券かDelivery注意)
o Seat number A-24 has been reserved for "a-concert" on April 2.
(Event ticket)
o 座席番号A-24は4月2日に「a-コンサート」のために予約されました。 (イベントチケット)
Note that P does not need to be described in terms of a natural language as long as the contents of the vouchers are specified. For example, a set of attribute name and value pairs described in XML can be employed to define the contents.
バウチャーのコンテンツが指定されている限り、自然言語でPが説明される必要はないことに注意してください。 例えば、コンテンツを定義するためにXMLで説明された1セットの属性名と値の組は雇うことができます。
2.2 Participants
2.2 関係者
There are four types of participants in the voucher trading model: issuer, holder, collector, and VTS provider. Their roles are as follows:
4つのタイプのバウチャーの取り引きモデルの関係者がいます: 発行人、所有者、コレクタ、およびVTSプロバイダー。 それらの役割は以下の通りです:
Issuer: Creates and issues a voucher. Guarantees contents of
the voucher.
発行人: バウチャーを創造して、発行します。 バウチャーの保証コンテンツ。
Fujimura & Eastlake Informational [Page 3] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[3ページ]のRFC3506バウチャー取引システム(VTS)行進
Holder (or user): Owns the vouchers. Transfers and redeems
the voucher to other users or collector.
所有者(または、ユーザ): バウチャーを所有しています。 他のユーザかコレクタにバウチャーを移して、身請けします。
Collector (or examiner): Collects or examines the voucher and
implements its promise. In general, compensated by goods or
services rendered.
コレクタ(または、試験官): 集まるか、バウチャーを調べて、または約束を履行します。 一般に、商品かレンダリングされたサービスで、代償しています。
VTS Provider: Provides a VTS and guarantees that a particular
voucher is not assigned to multiple holders or used multiple times
unless permitted for that voucher type.
VTSプロバイダー: VTSを提供して、そのバウチャータイプのために受入れられない場合特定のバウチャーが複数の所有者か中古の倍数回に選任されないのを保証します。
The IOTP model [IOTP] includes merchant, deliverer, consumer and other participants. They take various roles in the settlement because a merchant, for example, can be considered as an issuer, or holder depending on whether the merchant creates the voucher her/himself or purchases it from a wholesaler or manufacturer. A merchant can also be a collector if the shop collects gift certificate or coupons.
IOTPモデル[IOTP]は商人、配達人、消費者、および他の関係者を入れます。 商人がバウチャーのために自分で彼女の/を作成するか、または卸売業者かメーカーからそれを購入するかによって、発行人、または所有者であると例えば商人をみなすことができるので、それらは解決で様々な役割を果たします。 また、店が商品券かクーポンを集めるなら、商人はコレクタであるかもしれません。
2.3 Voucher Trading System (VTS)
2.3 バウチャー取引システム(VTS)
A voucher is generated by the issuer, traded among holders (users), and finally is collected by the collector:
所有者(ユーザ)の中で取り引きされた発行人によって発生して、コレクタはバウチャーを迎えるのに最終的に行きます:
<I, P, H> <I, P, H'> <I, P, H'>
Issuer I --------> User H ---------> User H' ---------> Collector
Issue Transfer Redemption
<I、P、H><I、P、H'><I、P、H'>発行人I'-------->ユーザH---------'>ユーザH'--------->コレクタ問題転送償却
Figure 1. Life cycle of vouchers
図1。 バウチャーのライフサイクル
The VTS provider supplies a VTS that enables vouchers to be circulated among the participants securely.
VTSプロバイダーはバウチャーが関係者の中をしっかりと循環するのを可能にするVTSを供給します。
A formal definition of VTS is as follows:
VTSの公式の定義は以下の通りです:
A voucher trading system (VTS) is a system that logically manages
a set of valid vouchers VVS, which is a subset of {<I, P, H> | I
in IS, P in PS, H in HS} where IS is the set of issuers, PS is the
set of promises, and HS is the set of holders; VTS prevents them
from being modified or reproduced except by the following three
transactions: issue, transfer, and redemption. The initial state
of the VVS is an empty set.
<I、P、H>| 中のIはそうです、PSのP、HSのH。Aバウチャー取引システム(VTS)が有効なバウチャーVVSの1セットを論理的に経営するシステムであり、部分集合がどれのものであるか、どこによるセットが発行人のものであり、PSが約束のセットであり、HSが所有者のセットであるということであるか。 VTSは、以下の3つの取引を除いて、彼らが変更されるか、または再生するのを防ぎます: 問題、転送、および償却。 VVSの初期状態は空集合です。
Note that this does not imply that VVS is stored physically in a
centralized database. For example, one implementation may store
vouchers in distributed smart cards carried by each holder [T00],
これが、VVSが集中データベースに物理的に格納されるのを含意しないことに注意してください。 例えば、1つの実現がそれぞれの所有者[T00]によって運ばれた分配されたスマートカードにバウチャーを格納するかもしれません。
Fujimura & Eastlake Informational [Page 4] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[4ページ]のRFC3506バウチャー取引システム(VTS)行進
or may store them in multiple servers managed by each issuer or
trusted third parties. This is a trust policy and/or
implementation issue [MF99].
または、各発行人か信頼できる第三者機関によって管理された複数のサーバにそれらを格納するかもしれません。 これは、信用方針、そして/または、導入問題[MF99]です。
Issue
An issue transaction is the action that creates the tuple of <I,
P, H> and adds it to the VVS with the issuer's intention.
問題An問題取引は<I、P、H>のtupleを作成して、発行人の意志でVVSにそれを加える動作です。
Transfer
A transfer transaction is the action that rewrites the tuple of
<I, P, H> (in VVS) as <I, P, H'> (H<>H') to reflect the original
holder H's intention.
転送A振替取引はオリジナルの所有者Hの意志を反映するために、<I、P、H'>(H<>H')として<Iのtuple、P、H>(VVSの)を書き直す動作です。
Redemption
There are two redemption transactions: presentation and
consumption.
償却Thereは2つの償却取引です: プレゼンテーションと消費。
A presentation transaction is the action that shows the tuple of
<I, P, H> (in VVS) to reflect the holder H's intention. In this
case, the ownership of the voucher is retained when the voucher is
redeemed, e.g., redemption (presentation) of licenses or
passports.
プレゼンテーション取引は所有者Hの意志を反映するために、<Iのtuple、P、H>(VVSの)を見せている動作です。 この場合バウチャーを身請けするとき、バウチャーの所有権を保有します、例えば、ライセンスかパスポートの償却(プレゼンテーション)。
A consumption transaction is the action that deletes the tuple of
<I, P, H> (in VVS) to reflect the holder H's intention and
properties of the voucher. The ownership of the voucher may be
voided or the number of times it is valid reduced when the voucher
is redeemed, e.g., redemption of event tickets or telephone cards.
消費取引は所有者Hのバウチャーの意志と所有地を反映するために、<Iのtuple、P、H>(VVSの)を削除する動作です。 バウチャーを身請けするとき、バウチャーの所有権が欠如したかもしれませんか、またはそれが有効であるという回の数は減少しました、例えば、イベントチケットかテレホン・カードの償却。
Note that one or more of these transactions can be executed as part of the same IOTP purchase transaction. See details in Section 6.
同じIOTP購買取引の一部としてこれらの取引の1つ以上を実行できることに注意してください。 セクション6で詳細を見てください。
3. VTS Requirements
3. VTS要件
A VTS must meet the following requirements
VTSは以下の必要条件を満たさなければなりません。
(1) It MUST handle diverse types of vouchers issued by different
issuers.
(1) それは異なった発行人によって発行されたさまざまのタイプのバウチャーを扱わなければなりません。
(2) It MUST prevent illegal acts such as alteration, forgery, and
reproduction, and ensure privacy.
(2) それは、変更や、偽造や、再現などの不法な行為を防いで、秘密を守らなければなりません。
(3) It MUST be practical in terms of implementation/operation cost
and efficiency.
(3) それは実現/営業経費と効率で実用的であるに違いありません。
Each of these requirements is discussed below in detail.
以下で詳細にそれぞれのこれらの要件について議論します。
Fujimura & Eastlake Informational [Page 5] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[5ページ]のRFC3506バウチャー取引システム(VTS)行進
3.1 Capability of handling diversity
3.1 取り扱いの多様性の能力
(a) Different issuers
(a) 異なった発行人
Unlike a digital cash system that handles only the currency issued by a specific issuer such as a central bank, the voucher trading system MUST handle vouchers issued by multiple issuers.
中央銀行などの特定の発行人によって支給された通貨だけを扱うデジタル・キャッシュシステムと異なって、バウチャー取引システムは複数の発行人によって発行されたバウチャーを扱わなければなりません。
(b) Various types of vouchers
(b) 様々なタイプのバウチャー
Unlike a digital cash system that only handles a currency, the system MUST handle various types of vouchers, such as gift certificates, coupons, and loyalty points.
通貨を扱うだけであるデジタル・キャッシュシステムと異なって、システムは様々なタイプのバウチャーを扱わなければなりません、商品券や、クーポンや、ロイヤルティポイントなどのように。
3.2 Ensuring security
3.2 セキュリティを確実にすること。
(c) Preventing forgery
(c) 偽造を防ぐこと。
Only the issuer can cause a valid voucher to be issued. It MUST NOT be possible for other parties to cause a valid voucher to be created.
発行人だけが有効なバウチャーを発行させることができます。 相手が有効なバウチャーを創造させるのは可能であるはずがありません。
(d) Preventing alteration
(d) 変更を防ぐこと。
Voucher MUST NOT be altered during circulation except that the transfer transaction, in which the voucher holder is rewritten, is permitted. Only the current holder can initiate a transfer transaction.
振替取引(バウチャー所有者は書き直される)が受入れられる以外に、流通の間、バウチャーを変更してはいけません。 現在の所有者だけが振替取引を開始できます。
(e) Preventing duplicate-redemption
(e) 写し償却を防ぐこと。
A voucher MUST NOT be redeemable once it has been consumed (the result of some redemption transactions). Only the holder can initiate a redemption transaction.
それがいったん消費されると(いくつかの償却取引の結果)、バウチャーは買戻し可能であるはずがありません。 所有者だけが償却取引を開始できます。
(f) Preventing reproduction
(f) 再現を防ぐこと。
Voucher MUST NOT be reproduced while in circulation. That is, there must be only one valid holder of any particular voucher at any particular time.
流通にはある間、バウチャーを再生させてはいけません。 すなわち、特定の何時でも、どんな特定のバウチャーの1個の有効な所有者しかもいないに違いありません。
(g) Non-repudiation
(g) 非拒否
It SHOULD NOT be possible to the issuer to repudiate the issuance, or the holder to repudiate the transfer or redemption of a voucher, after it is issued, transferred or redeemed.
それ、SHOULD NOT、発行を否認する発行人、またはバウチャーの転送か償却を否認する所有者に可能であってください、それを発行するか、移すか、または償却した後に。
Fujimura & Eastlake Informational [Page 6] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[6ページ]のRFC3506バウチャー取引システム(VTS)行進
(h) Ensuring privacy
(h) 秘密を守ること。
Current and previous holders of a voucher SHOULD be concealed from someone coming into possession of the voucher.
現在で前の所有者、バウチャーSHOULDでは、だれかから、バウチャーの所有物に入りながら、隠してください。
(i) Trust manageability
(i) 管理可能性を信じてください。
If a wide variety of vouchers are in circulation, it might be difficult for users to judge whether a voucher can be trusted or not. To assist such users, a trust management function that verifies the authenticity of a voucher SHOULD be supported.
さまざまなバウチャーが流通中であるなら、ユーザが、バウチャーを信じることができるかどうか判断するのは、難しいかもしれません。 そのようなユーザ、バウチャーSHOULDの信憑性について確かめる信用管理機能を補助するには、支持されてください。
3.3 Ensuring practicality
3.3 実用性を確実にすること。
(j) Scalability
(j) スケーラビリティ
A single centralized broker that sells all types of vouchers, or a centralized authority that authenticates all issuers or other participants, SHOULD NOT be assumed. A system that relies on a single centralized organization is excessively frail; failure in that organization causes complete system failure.
すべてのタイプのバウチャー、または集結された権威にそれを販売する独身の集結されたブローカーはすべての発行人か他の関係者を認証します、SHOULD NOT。想定されます。 ただ一つの集権組織に依存するシステムは過度にもろいです。 その組織における失敗は完全なシステム障害を引き起こします。
(k) Efficiency
(k) 効率
It MUST be possible to implement VTS efficiently. Many applications of vouchers, e.g., event ticket or transport passes, require high performance, especially when the voucher is redeemed.
効率的にVTSを実行するのは可能であるに違いありません。 特にバウチャーを身請けするとき、バウチャーの多くのアプリケーション(例えば、イベントチケットか輸送パス)が、高性能を必要とします。
(l) Simplicity
(l) 簡単さ
It SHOULD be possible to implement VTS simply. Simplicity is important to reduce the cost of implementation. It is also important in understanding the system, which is necessary for trust in the system.
それ、SHOULD、単にVTSを実行するのにおいて、可能であってください。 簡単さは、実現のコストを削減するために重要です。 また、それもシステムを理解するのにおいて重要です。(システムがシステムへの信用に必要です)。
4. Scope of VTS Specifications
4. VTS仕様の範囲
To implement a VTS, Voucher Trading Protocol (VTP), VTS Application Programming Interface (VTS-API), and Generic Voucher Language (GVL) must be developed. The objectives, benefits, and limitations of standardization for each specification are discussed below.
VTS、Voucher Tradingプロトコル(VTP)、VTS Application Programming Interface(VTS-API)、およびGeneric Voucher Language(GVL)を実行するのは開発していなければなりません。 以下で各仕様のための標準化の目的、利益、および制限について議論します。
4.1 Voucher Trading Protocol
4.1 バウチャーの取り引きプロトコル
To achieve interoperability among multiple VTSs developed by independent VTS Providers, standard protocols for issuing, transferring, or redeeming vouchers will be needed. However, there are several ways of implementing VTS. For discount coupons or event
独立しているVTS Providersによって開発された複数のVTSsの中で相互運用性を達成するために、バウチャーを発行するか、移すか、または身請けするための標準プロトコルが必要でしょう。 しかしながら、VTSを実行するいくつかの方法があります。 割引券か出来事のために
Fujimura & Eastlake Informational [Page 7] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[7ページ]のRFC3506バウチャー取引システム(VTS)行進
tickets, for example, the smart-card-based decentralized offline VTS is often preferred, whereas for bonds or securities, the centralized online VTS may be preferred. It is impractical to define any standard protocol at this moment.
チケット、例えば、集結されたオンラインVTSは債券か証券で好まれるかもしれませんが、賢いカードベースの分散オフラインVTSはしばしば好まれます。 この瞬間どんな標準プロトコルも定義するのは非実用的です。
4.2 VTS-API
4.2 VTS-アピ
To provide freedom in terms of VTS selection for issuers and application developers, a standard Voucher Trading System Application Programming Interface (VTS-API) that can encapsulate VTS implementations should be specified. It allows a caller application to issue, transfer, and redeem voucher in a uniform manner independent of the VTS implementation. Basic functions, i.e., issue, transfer, and redeem, provided by VTS-API can be straightforwardly derived from the VTS model described in this document. More design details of the VTS-API will be discussed in a separate document or a separate VTS-API specification.
VTS選択で発行人とアプリケーション開発者、VTS実現を要約できる標準のVoucher Trading System Application Programming Interface(VTS-API)に自由を供給するのは指定されているべきです。 それで、訪問者アプリケーションは、一定の方法でVTS実現の如何にかかわらずバウチャーを発行して、移して、身請けします。 本書では説明されたVTSモデルからVTS-APIをまっすぐ得ることができるなら、すなわち、基本機能、問題は、移して、償却します。 別々のドキュメントか別々のVTS-API仕様でVTS-APIの、よりその他のデザインの詳細について議論するでしょう。
4.3 Generic Voucher Language
4.3 一般的なバウチャー言語
To satisfy the diverse requirements placed on VTS (see Section 3), a standard Generic Voucher Language (GVL) that realizes various voucher properties should be specified. This approach ensures that VTS is application independent. The language should be able to define diverse Promises P of the voucher <I, P, H> to cover tickets, coupons, loyalty points, and gift certificates uniformly. Specifying I and H is a VTS implementation issue and can be achieved by using a public key, hash of a public key, URI or other names with scope rule.
VTS(セクション3を見る)に置かれたさまざまの要件を満たすために、様々なバウチャーの特性がわかる標準のGeneric Voucher Language(GVL)は指定されるべきです。 このアプローチは、VTSがアプリケーション独立者であることを確実にします。 言語はバウチャー<IのさまざまのPromises Pを定義できるべきです、P、一様にチケット、クーポン、ロイヤルティポイント、および商品券をカバーするH>。 指定している私とHは、VTS導入問題であり、公開鍵(範囲規則の公開鍵、URIまたは他の名前の細切れ肉料理)を使用することによって、達成できます。
In the following section, we discuss GVL Requirements in detail.
以下のセクションで、私たちは詳細にGVL Requirementsについて議論します。
5. GVL Requirements
5. GVL要件
5.1 Semantics
5.1 意味論
Semantics supported by the language and their requirements levels are described below in detail.
言語によって支持された意味論とそれらの要件レベルは以下で詳細に説明されます。
(a) Validity control
(a) 正当性コントロール
The invalidation (punching) method that is executed when the voucher is redeemed depends on the type of the voucher. For example, a loyalty point will be invalidated if the point is redeemed but a membership card can be used repeatedly regardless of the number of times presented. The language MUST be able to define how validity is modified. Additionally, the language MUST be able to define the validity period, start date and end date.
バウチャーを身請けするとき実行する無効にする(パンチ)方法はバウチャーのタイプに頼っています。 例えば、ポイントが救われると、ロイヤルティポイントは無効にされるでしょうが、提示された回数にかかわらず繰り返して会員証を使用できます。 言語は正当性がどう変更されているかを定義できなければなりません。 さらに、言語は有効期間、スタート日、および終了日を定義できなければなりません。
Fujimura & Eastlake Informational [Page 8] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[8ページ]のRFC3506バウチャー取引システム(VTS)行進
(b) Transferability control
(b) 転々流通性コントロール
Some types of vouchers require transferability. The language MUST be able to specify if a voucher can be transferred.
何人かのタイプのバウチャーは転々流通性を必要とします。 言語は、バウチャーを移すことができるかどうか指定できなければなりません。
(c) Circulation control
(c) 循環制御
Depending on the type of the voucher, various circulation requirements or restrictions must be satisfied [F99], for example, only qualified shops can issue particular vouchers or only a certain service provider can punch (invalidate) particular vouchers. The language SHOULD be able to specify such circulation requirements.
バウチャー、様々な流通要件または制限のタイプに頼るのを満たさなければならない[F99]、例えば、適切な店だけが特定のバウチャーを発行できますか、またはさもなければ、あるサービスプロバイダーだけが特定のバウチャーを殴ることができます(無効にします)。 言語SHOULD、そのような流通要件を指定できてください。
(d) Anonymity control
(d) 匿名コントロール
Different types of voucher will require different levels of anonymity. The language SHOULD be able to achieve the required level of anonymity.
異なったタイプのバウチャーは異なったレベルの匿名を必要とするでしょう。 言語SHOULD、必要なレベルの匿名を達成できてください。
(e) Understandability
(e) 理解性
The terms and description of a voucher SHOULD be objectively understood by the participants, because this will contribute to reducing the number of disputes on the interpretation of the vouchers promised.
バウチャーSHOULDの用語と記述が関係者に客観的に解釈されて、これが減少に貢献するので、バウチャーの解釈の論争の数は約束しました。
(f) State manageability
(f) 州の管理可能性
Some types of vouchers have properties the values of which may change dynamically while in circulation, e.g., payment status, reservation status, or approval status. The language MAY support the definition of such properties.
何人かのタイプのバウチャーには、例えばそれの値が流通にある間にダイナミックに変化するかもしれない特性、支払い状態、予約状況、または承認の状態がいます。 言語はそのような特性の定義を支持するかもしれません。
(g) Composability
(g) Composability
Some types of vouchers consist of several sub-vouchers, which may be issued separately from the original vouchers typically because the vouchers are issued by different organizations or issued at different times. The language MAY support compound vouchers composed of multiple sub-vouchers.
何人かのタイプのバウチャーはいくつかのサブバウチャーから成ります。(バウチャーが異なった組織によって発行されるか、またはいろいろな時間に発行されるので、バウチャーは別々に原始帳票から通常発行されるかもしれません)。 言語は複数のサブバウチャーで構成された合成バウチャーを支持するかもしれません。
5.2 Syntax
5.2構文
To achieve consistency with other related standards shown below, the syntax of the language MUST be based on XML [XML].
以下に示される他の関連する規格で一貫性を獲得するために、言語のシンタックスをXML[XML]に基礎づけなければなりません。
Fujimura & Eastlake Informational [Page 9] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[9ページ]のRFC3506バウチャー取引システム(VTS)行進
The language syntax MUST enable any application-specific property, e.g., seat number, flight number, etc. to be defined. A schema definition language that can be translated into application-specific DTDs may be needed.
言語構文は、どんなアプリケーション特有の性質、座席番号、例えば飛行番号なども定義されるのを可能にしなければなりません。 アプリケーション特有のDTDに翻訳できる図式定義言語が必要であるかもしれません。
5.3 Security
5.3 セキュリティ
The language MUST provide the parameters necessary to establish security. Security requirements, however, mainly follow VTS requirements described in Section 3 rather than GVL requirements.
言語はセキュリティを証明するのに必要なパラメタを提供しなければなりません。 しかしながら、セキュリティ要件はGVL要件よりむしろセクション3で説明されたVTS要件に主に続きます。
5.4 Efficiency
5.4 効率
The vouchers may be stored in a smart card or PDA with a restricted amount of memory. Large definitions may incur long transfer and processing times, which may not be acceptable. The language SHOULD enable the efficient definition of vouchers
バウチャーはスマートカードかPDAに制限されたメモリー容量で格納されるかもしれません。 大きい定義は長い転送と処理時間を被るかもしれません。(時間は許容できないかもしれません)。 言語SHOULDはバウチャーの効率的な定義を可能にします。
5.5 Coordination
5.5 コーディネート
The language specification SHOULD be consistent with the following specifications:
言語仕様SHOULD、以下の仕様と一致してください:
(1) Internet Open Trading Protocol v1.0 [IOTP]
(2) XML-Signature [XMLDSIG]
(3) Extensible Markup Language (XML) Recommendation [XML]
(4) ECML Version 2 [ECML]
(1) インターネットオープンTradingプロトコルv1.0[IOTP](2)XML-署名[XMLDSIG](3)拡張マークアップ言語(XML)推薦[XML](4)ECMLバージョン2[ECML]
5.6 Example of GVL
5.6 GVLに関する例
An example of a voucher definition in GVL is described below. This example defines a five dollar discount coupon for specific merchandise, a book with ISBN number 0071355014. This coupon is circulated using a VTS called "Voucher Exchanger". To claim this offer, one coupon must be spent. The coupon is valid from April 1st in 2001 to March 31st in 2002.
GVLとのバウチャー定義に関する例は以下で説明されます。 この例はISBN No.0071355014で特定の商品、本のための5ドルの割引券を定義します。 このクーポンは、「バウチャー交換器」と呼ばれるVTSを使用することで循環します。 この申し出を要求するために、1個のクーポンを費やさなければなりません。 クーポンは2002年に2001年の4月1日から3月31日まで有効です。
<?xml version="1.0"?>
<Voucher xmlns="urn:ietf:params:xml:schema:vts-lang"
xmlns:vts="http://www.example.com/vts">
<Title>IOTP Book Coupon</Title>
<Description>$5 off IOTP Book</Description>
<Provider name="Voucher Exchanger">
<vts:Version>VE2.31</vts:Version>
</Provider>
<Value type="discount" spend="1">
<Fixed amount="5" currency="USD"/>
</Value>
<?xmlバージョン= 「1インチ?」><バウチャーxmlns=「つぼ:ietf:params:xml:図式: vts-lang」xmlns: vts=「「><vts: バージョン>VE2.31</vts: バージョン></プロバイダー><Valueは=をタイプする」という http://www.example.com/vts 「><Title>IOTP Book Coupon</タイトル><記述>5ドルの取り止めになっているIOTP Book</記述><Provider名=」バウチャーExchanger割り引き」は「U.S.ドル」/></価値の=「1インチの><Fixed量=」の5インチの通貨=>を費やします。
Fujimura & Eastlake Informational [Page 10] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[10ページ]のRFC3506バウチャー取引システム(VTS)行進
<Merchandise>
<bk:Book xmlns:bk="http://www.example.com/bk"
bk:isbn="0071355014"/>
</Merchandise>
<ValidPeriod start="2001-04-01" end="2002-03-31"/>
</Voucher>
<商品><Bk: xmlnsを予約してください: Bkは" http://www.example.com/bk "Bkと等しいです: 「0071355014」/></商品><isbn=ValidPeriodは=「2001年4月1日」「2002年3月31日」/>エンド=</バウチャー>を始動します。
6. Application Scenarios
6. アプリケーションシナリオ
This section describes, as a typical electronic commerce example involving advertisement, payment, and delivery transactions, the use of vouchers and VTS, and shows that vouchers can be used as an effective way to coordinate autonomous services that have not yet established trust among each other.
このセクションは、バウチャーとVTSの使用を広告、支払い、および配送取引にかかわる典型的な電子商取引の例と説明して、互いの中でまだ信用を確立していない自動サービスを調整する効果的な方法としてバウチャーを使用できるのを示します。
Figure 2 shows a typical electronic commerce example of a consumer searching for goods or services and making a purchase:
図2は消費者の典型的な電子商取引の例が商品かサービスを捜し求めて、仕入れるのを示します:
----------
------------------------------------------->| Ad |
| (1) Acquire a coupon | Agency |
| ----------
|
| (2) Send payment information ----------
| --------------------------------------->| Payment |
| | Acquire a gift certificate | Handler |
| | ----------
v v (3) Transfer the coupon &
---------- gift certificate ----------
| Consumer |<------------------------------------>| Merchant |
---------- Acquire an exchange ticket & ----------
^ loyalty points
|
| (4) Transfer the exchange ticket ----------
------------------------------------------->| Deliverer|
Supply goods or services | Handler |
----------
---------- ------------------------------------------->| 広告| | (1) クーポンを入手してください。| 政府機関| | ---------- | | (2) 決済情報を送ってください。---------- | --------------------------------------->| 支払い| | | 商品券を入手してください。| 操作者| | | ---------- v(3)に対して、クーポンを移してください。---------- 商品券---------- | 消費者|<------------------------------------>| 商人| ---------- 商品券を入手してください。---------- ^ロイヤルティポイント| | (4) 商品券を移してください。---------- ------------------------------------------->| 配達人| 供給商品かサービス| 操作者| ----------
Figure 2. Application example of vouchers
図2。 バウチャーに関するアプリケーションの例
(1) Use a search engine to find the desired goods or services and
acquire a coupon from an ad agency that represents the right to
purchase the goods or services at a discounted price.
割引値段で商品かサービスを購入する右を表す広告代理店から、(1) サーチエンジンを使用して、必要な商品かサービスを見つけて、クーポンを入手してください。
(2) Acquire a gift certificate from a payment handler in exchange for
cash or payment information.
(2) 現金か決済情報と引き換えに支払い操作者から商品券を入手してください。
Fujimura & Eastlake Informational [Page 11] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[11ページ]のRFC3506バウチャー取引システム(VTS)行進
(3) Transfer the coupon and gift certificate to the merchant, and in
exchange acquire an exchange ticket and loyalty points.
(3) クーポンと商品券を商人に移してください、そして、交換では、商品券とロイヤルティポイントを入手してください。
(4) Transfer the exchange ticket to the deliverer handler and receive
the goods or services.
(4) 配達人の操作者に商品券を移してください、そして、商品かサービスを受けてください。
In this example, the coupon, gift certificate, and exchange ticket each represent the media that yields the above four transactions.
この例では、クーポン、商品券、および商品券はそれぞれ上の4つの取引をもたらすメディアを代表します。
Note that it is not necessary to trust the participants involved in the transactions, but to trust the vouchers themselves. In other words, there is no need to exchange contracts among the participants beforehand if the vouchers themselves are trusted.
しかし取引にかかわる関係者がバウチャー自体を信じると信じるのは必要でないことに注意してください。 言い換えれば、バウチャー自体が信じられるなら、あらかじめ関係者の中で契約を交換する必要は全くありません。
Take the exchange ticket as an example; even if the delivery handler does not trust the consumer, the merchant that issued the exchange ticket is trusted, and if the VTS guarantees that there is no duplication in the trading process of the exchange ticket, there is no problem in swapping the exchange ticket for the goods or services. In the same way, even if the merchant does not trust the delivery handler, the issuance of the exchange ticket can be verified, and if the VTS guarantees that there is no duplication in the trading process of the exchange ticket, there is no problem in swapping the exchange ticket for the goods or services (Fig. 3). In other words, if there is trust in the issuer and the VTS, trust among the participants involved in the transactions is not required.
例として商品券をみなしてください。 配送操作者が消費者を信じないでも、商品券を産出した商人は信じられます、そして、VTSが、複製が全く商品券の取り引き過程にないのを保証するなら、商品かサービスに商品券を交換するのにおいて問題が全くありません。 同様に、商人が配送操作者を信じないでも、商品券の発行について確かめることができます、そして、VTSが、複製が全く商品券の取り引き過程にないのを保証するなら、商品かサービス(図3)に商品券を交換するのにおいて問題が全くありません。 言い換えれば、発行人とVTSへの信用があれば、取引にかかわる関係者の中の信用は必要ではありません。
Exchange Exchange
---------- ticket ---------- ticket ----------
| Consumer |-------->| Delivery |-------->| Merchant |
| |<--------| Handler |<--------| |
---------- Goods or ---------- Goods or ----------
services services
交換交換---------- チケット---------- チケット---------- | 消費者|、-、-、-、-、-、-、--、>| 配送|、-、-、-、-、-、-、--、>| 商人| | | <、-、-、-、-、-、-、--、| 操作者| <、-、-、-、-、-、-、--、|、| ---------- または商品。---------- または商品。---------- サービスサービス
Figure 3. Coordination of untrusted participants
using exchange ticket
図3。 商品券を使用している信頼されていない関係者のコーディネート
In general, it is more difficult to trust individuals than companies, so this characteristic of VTS is especially important.
一般に、VTSのこの特性が特に重要であることで、個人を信じるのは会社より難しいです。
Moreover, the transactions involving vouchers have desirable features with respect to privacy protection. For example, in the above exchange ticket scenario, the consumer can designate the delivery service for himself, so the merchant does not even need to know any personal information such as the delivery address. Furthermore, by designating a convenience store etc. as the receiving point, the delivery service does not need to know the address of the consumer.
そのうえ、バウチャーにかかわる取引はプライバシー保護に関して望ましい特徴を持っています。 例えば、上の商品券シナリオでは、消費者が自分のためにデリバリ・サービスを指定できるので、商人は品物の配達先などのどんな個人情報も知る必要さえありません。 その上、受信ポイントとしてコンビニエンスストアなどを指定することによって、デリバリ・サービスは消費者のアドレスを知る必要はありません。
Fujimura & Eastlake Informational [Page 12] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[12ページ]のRFC3506バウチャー取引システム(VTS)行進
7. Q & A
7. Q&A
- Is it possible to implement a VTS using digital certificates?
- デジタル証明書を使用することでVTSを実行するのは可能ですか?
If transferability is not required, a voucher can be easily
implemented as a digital certificate, i.e., Signed_I(I, P, H),
where the phrase "Signed_I" means that the entire block is signed
by the issuer's digital signature. If transferability is
required, then H is changed during the transfer, i.e., the
signature is broken. Additionally, online data base checking or
tamper-resistant devices are required to prevent duplicate-
redemption.
転々流通性は必要でないなら、すなわち、デジタル証明書、Signed_I(句は「_Iにサインした」)(I、P、H)が、発行人のデジタル署名で全体のブロックがサインされることを意味するとき、容易にバウチャーを実行できます。 転々流通性を必要とするなら、転送の間、Hを変えます、すなわち、署名は中断しています。 さらに、防ぐベースの照合か耐タンパー性装置が必要であるオンラインデータは償却をコピーします。
- What is the difference from digital-cash?
- デジタル・キャッシュからの違いは何ですか?
VTS must handle various types of vouchers, such as gift
certificates, coupons, or loyalty points unlike a digital cash
system which handles only currency. Additionally, vouchers are
issued by different issuers.
VTSは様々なタイプのバウチャーを扱わなければなりません、通貨だけを扱うデジタル・キャッシュシステムと異なった商品券、クーポン、またはロイヤルティポイントなどのように。 さらに、バウチャーは異なった発行人によって発行されます。
- Is it possible to support "digital property rights?
- 「デジタル財産権?」を支持するのは可能ですか?
Digital property rights can be represented as a voucher and can be
traded using VTS. However, some protected rendering system would
be required to regenerate the digital contents securely in order
to support digital property rights. These requirements are out of
scope of VTS.
デジタル財産権をバウチャーとして表すことができて、VTSを使用することで取り引きできます。 しかしながら、何らかの保護された表現システムが、デジタル財産権を支持するためにしっかりとデジタル・コンテンツを作り直すのに必要でしょう。 VTSの範囲の外にこれらの要件があります。
8. Security Considerations
8. セキュリティ問題
Security issues are discussed in Section 3.2 and 5.3.
セクション3.2と5.3で安全保障問題について議論します。
9. Acknowledgments
9. 承認
I would like to thank Masayuki Terada and Perry E. Metzger, for their valuable comments.
彼らの貴重なコメントについてMasayuki TeradaとペリーE.メッツガーに感謝申し上げます。
10. References
10. 参照
[ECML] ECML Version 2, Work in Progress.
[ECML]ECMLバージョン2、処理中の作業。
[F99] K. Fujimura, H. Kuno, M. Terada, K. Matsuyama, Y. Mizuno,
and J. Sekine, "Digital-Ticket-Controlled Digital Ticket
Circulation", 8th USENIX Security Symposium, August 1999.
[F99] K.藤村、H.クーノー、M.Terada、K.松山、Y.美津濃、およびJ.セキネ、「デジタルチケットが制御されたデジタルチケット流通」、第8USENIXセキュリティシンポジウム(1999年8月)。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Fujimura & Eastlake Informational [Page 13] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[13ページ]のRFC3506バウチャー取引システム(VTS)行進
[IOTP] Burdett, D., "The Internet Open Trading Protocol", RFC
2801, April 2000.
[IOTP] 2000年4月のバーデット、D.、「インターネットの開いている取り引きプロトコル」RFC2801。
[MF99] K. Matsuyama and K. Fujimura, "Distributed Digital-Ticket
Management for Rights Trading System", 1st ACM Conferences
on Electronic Commerce, November 1999.
[MF99] K.松山とK.藤村、「権利取引システムのための分配されたデジタルチケット管理」、電子通商での最初のACMコンファレンス、1999年11月。
[T00] M. Terada, H. Kuno, M. Hanadate, and K. Fujimura, "Copy
Prevention Scheme for Rights Trading Infrastructure", 4th
Smart Card Research and Advanced Application Conference
(CARDIS 2000), September 2000.
[T00] 第4M.Terada、H.クーノー、M.Hanadate、K.藤村、「インフラストラクチャを取り引きする権利のコピー防止計画」、スマートカード研究、および高度なアプリケーションコンファレンス(CARDIS2000)(2000年9月)。
[XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A
W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October
2000.
[XML] 「言語(XML)1.0(第2版)への広げることができるマーク」、W3C推薦、<http://www.w3.org/TR/REC-xml>、2000年10月。
[XMLDSIG] "XML-Signature Syntax and Processing", A W3C Proposed
Recommendation, <http://www.w3.org/TR/xmldsig-core>, August
2001.
W3Cは、[XMLDSIG]「XML-署名構文と処理」よう提案しました。推薦、<xmldsig http://www.w3.org/TR/コア>、2001年8月。
11. Authors' Addresses
11. 作者のアドレス
Ko Fujimura NTT Corporation 1-1 Hikari-no-oka Yokosuka-shi Kanagawa, 239-0847 JAPAN
光ノー、がokaしているコー藤村NTT社1-1の横須賀市239-0847神奈川(日本)
Phone: +81-(0)468-59-3814 Fax: +81-(0)468-59-8329 EMail: fujimura@isl.ntt.co.jp
以下に電話をしてください。 +81(0)468-59-3814Fax: +81 -(0) 468-59-8329 メールしてください: fujimura@isl.ntt.co.jp
Donald E. Eastlake 3rd Motorola 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3モトローラ155ビーバー通りMA01757ミルフォード(米国)
Phone: +1-508-851-8280 EMail: Donald.Eastlake@motorola.com
以下に電話をしてください。 +1-508-851-8280 メールしてください: Donald.Eastlake@motorola.com
Fujimura & Eastlake Informational [Page 14] RFC 3506 Voucher Trading System (VTS) March 2003
2003年の藤村とイーストレーク情報[14ページ]のRFC3506バウチャー取引システム(VTS)行進
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Fujimura & Eastlake Informational [Page 15]
藤村とイーストレークInformationalです。[15ページ]
一覧
スポンサーリンク
