RFC2935 日本語訳
2935 Internet Open Trading Protocol (IOTP) HTTP Supplement. D.Eastlake 3rd, C. Smith. September 2000. (Format: TXT=16168 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Eastlake
Request for Comments: 2935 Motorola
Category: Standards Track C. Smith
Royal Bank of Canada
September 2000
コメントを求めるワーキンググループD.イーストレークの要求をネットワークでつないでください: 2935年のモトローラカテゴリ: 標準化過程C.スミスカナダ王立銀行2000年9月
Internet Open Trading Protocol (IOTP) HTTP Supplement
インターネットの開いている取り引きプロトコル(IOTP)HTTP補足
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
Internet Open Trading Protocol (IOTP) messages will be carried as Extensible Markup Language (XML) documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties.
拡張マークアップ言語(XML)が記録するようにインターネットオープンTradingプロトコル(IOTP)メッセージは伝えられるでしょう。 そういうものとして、トランスポート層へのマッピングの目標は基本的なXMLドキュメントが首尾よく様々なパーティーの間まで運ばれるのを保証することです。
This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1.
このドキュメントはHyper Text Transportプロトコル(HTTP)のためのそのマッピング、バージョン1.0と1.1について説明します。
Table of Contents
目次
1. Introduction................................................... 2 2. HTTP Servers and Clients....................................... 2 3. HTTP Net Locations............................................. 2 4. Consumer Clients............................................... 2 4.1 Starting the IOTP Client and the Merchant IOTP Server.......... 3 4.2 Ongoing IOTP Messages.......................................... 3 4.3 Stopping an IOTP Transaction................................... 4 5. Starting the Payment handler and Deliverer IOTP Servers........ 5 6. Security Considerations........................................ 5 7. IANA Considerations............................................ 5 8. References..................................................... 6 9. Authors' Addresses............................................. 7 10. Full Copyright Statement....................................... 9
1. 序論… 2 2. HTTPサーバとクライアント… 2 3. HTTPネット位置… 2 4. 消費者クライアント… 2 4.1 IOTPクライアントと商人IOTPサーバを始めます… 3 4.2 進行中のIOTPメッセージ… 3 4.3 IOTPトランザクションを止めます… 4 5. Payment操作者とDeliverer IOTP Serversを始動します… 5 6. セキュリティ問題… 5 7. IANA問題… 5 8. 参照… 6 9. 作者のアドレス… 7 10. 完全な著作権宣言文… 9
Eastlake & Smith Standards Track [Page 1] RFC 2935 IOTP HTTP Supplement September 2000
イーストレークとスミスStandardsはIOTP HTTP補足2000年9月にRFC2935を追跡します[1ページ]。
1. Introduction
1. 序論
Internet Open Trading Protocol (IOTP) [RFC2801] messages will be carried as XML [XML] documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties.
XML[XML]が記録するようにインターネットオープンTradingプロトコル(IOTP)[RFC2801]メッセージは伝えられるでしょう。 そういうものとして、トランスポート層へのマッピングの目標は基本的なXMLドキュメントが首尾よく様々なパーティーの間まで運ばれるのを保証することです。
This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2616].
このドキュメントはHyper Text Transportプロトコルのためのそのマッピング(HTTP)、バージョン1.0と1.1[RFCs1945、2616]について説明します。
There may be future documents describing IOTP over email (SMTP), TCP, cable TV, or other transports.
メール(SMTP)の上でIOTPについて説明する将来のドキュメント、TCP、ケーブルテレビ、または他の輸送があるかもしれません。
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]で説明されるように本書では解釈されることであるべきですか?
2. HTTP Servers and Clients
2. HTTPサーバとクライアント
The structure of IOTP maps on to the structure of HTTP in the following way:
以下の方法でHTTPの構造へのIOTP地図の構造:
The merchant, payment handler, delivery handler, and customer care
roles are all represented by HTTP servers. Each may be
represented by a separate server, or they may be combined in any
combination.
商人、支払い操作者、配送操作者、および顧客ケアの役割はすべてHTTPサーバによって代理をされます。 それぞれが別々のサーバによって表されるかもしれませんか、またはそれらはどんな組み合わせでも結合されるかもしれません。
The consumer role is represented by an HTTP client.
消費者の役割はHTTPクライアントによって表されます。
Note: A Merchant, may act in the role of a consumer, for example to deposit electronic cash. In this case the Merchant, as an organization rather than as a role, would need to be supported by an HTTP client.
以下に注意してください。 マーチャント、例えば電子現金を預けるために消費者の役割で行動するかもしれません。 この場合、役割としてというよりむしろ組織として、マーチャントは、HTTPクライアントによってサポートされる必要があるでしょう。
3. HTTP Net Locations
3. HTTPネット位置
The Net Locations contained within the IOTP specification are all URIs [RFC 2396]. If a secure connection is required or desired a secure channel that both the HTTP Server and Client support MUST be used. Examples of such channels are SSL version 3 or TLS [RFC 2246].
IOTP仕様の中に含まれたネットLocationsはすべてURI[RFC2396]です。 安全な接続が必要である、または望まれているなら、HTTP ServerとClientの両方が支える安全なチャンネルを使用しなければなりません。 そのようなチャンネルに関する例は、SSLバージョン3かTLS[RFC2246]です。
4. Consumer Clients
4. 消費者クライアント
In most environments, the consumer agent will initially be an HTML browser. However, current browsers do not provide the needed capability to act as an agent for the consumer for an IOTP transaction. This leads to two requirements:
ほとんどの環境で、消費者エージェントは初めは、HTMLブラウザになるでしょう。 しかしながら、現在のブラウザは消費者のために手先になる必要な能力をIOTPトランザクションに提供しません。 これは2つの要件に通じます:
Eastlake & Smith Standards Track [Page 2] RFC 2935 IOTP HTTP Supplement September 2000
イーストレークとスミスStandardsはIOTP HTTP補足2000年9月にRFC2935を追跡します[2ページ]。
a method of starting and passing control to the IOTP client, and
そしてIOTPクライアントに始まって、コントロールを渡すメソッド。
a method of closing down the IOTP client cleanly and passing control back to the HTML browser once the IOTP Transaction has finished.
清潔にIOTPクライアントを閉鎖して、IOTP Transactionがいったん終わるとHTMLブラウザにコントロールを戻すメソッド。
4.1 Starting the IOTP Client and the Merchant IOTP Server
4.1 IOTPクライアントと商人IOTPサーバを始めること。
At some point, the HTTP client at the consumer will send an HTTP request that is interpreted as an "IOTP Startup Request" by the Merchant HTTP server. This might, for example, be the result of clicking on a "pay" button. This message is a stand-in for a request message of some form and the Merchant Server will respond with the first IOTP Message in the form of an XML document.
何らかのポイントでは、消費者のHTTPクライアントは「IOTP始動要求」としてマーチャントHTTPサーバによって解釈されるHTTP要求を送るでしょう。例えば、これは「賃金」ボタンをクリックするという結果であるかもしれません。 このメッセージは何らかのフォームに関する要求メッセージのための代役です、そして、マーチャントServerは最初のIOTP Messageと共にXMLドキュメントの形で応じるでしょう。
The MIME type for all IOTP messages is: "APPLICATION/IOTP"; however "APPLICATION/X-IOTP" has been in use for experimentation and development and SHOULD also be recognized. See section 7 below for the MIME type registration template for APPLICATION/IOTP. Because HTTP is binary clean, no content-transfer-encoding is required. (See [RFC 2376] re the application/xml type which has some similar considerations.)
すべてのIOTPメッセージのためのMIMEの種類は以下の通りです。 「アプリケーション/IOTP」。 しかしながら、「アプリケーション/X-IOTP」は、実験と開発に使用中であり、また、認識されるべきです。 MIMEの種類登録テンプレートのためにAPPLICATION/IOTPに関して下のセクション7を見てください。 HTTPが清潔な状態で2進であるので、満足している転送コード化は必要ではありません。 (アプリケーション/xmlタイプに関してどれにいくつかの同様の問題があるかを見てください[RFC2376]。)
This HTTP response will be interpreted by the HTML browser as a request to start the application associated with MIME type "APPLICATION/IOTP", and to pass the content of this message to that application.
このHTTP応答はMIMEの種類「アプリケーション/IOTP」に関連しているアプリケーションを始めて、このメッセージの内容をそのアプリケーションに通過するという要求としてHTMLブラウザによって解釈されるでしょう。
At this point, the IOTP client will be started and have the first message.
ここに、IOTPクライアントは、始められて、最初のメッセージを持つでしょう。
IOTP messages are short-lived. Therefore, the HTTP server SHOULD avoid having its responses cached. In HTTP V1.0, the "nocache" pragma can be used. This can be neglected on SSL/TLS secured connections which are not cached and on HTTP POST requests in HTTP v1.1 as in v1.1 POST responses are not cached.
IOTPメッセージは短命です。 したがって、HTTPサーバSHOULDは、応答をキャッシュさせるのを避けます。 HTTP V1.0では、"nocache"pragmaを使用できます。 キャッシュされないで、またポストがv1.1ポストの応答のようにHTTP v1.1で要求するHTTPでキャッシュされない接続であることが固定されたSSL/TLSでこれを無視できます。
4.2 Ongoing IOTP Messages
4.2 進行中のIOTPメッセージ
Data from earlier IOTP Messages in a transaction MUST be retained by the IOTP Client so that it may (1) be copied to make up part of later IOTP messages, (2) used in calculations to verify signatures in later IOTP message, (3) be resent in some cases where a request has timed out without response, (4) used as input to the Customer Care role in later versions of IOTP, etc. The way in which the data is copied depends on the IOTP Transaction. The data MUST be retained until the end of the transaction, whether by success, failure, or cancelation, and as long thereafter as it is desired for any of the parties to inquire into it.
トランザクションにおける以前のIOTP Messagesからのデータがそうであるに違いない、(3) (1) そうすることができるようにIOTP Clientによって保有されて、コピーして、後のIOTPメッセージの一部を作ってくださいといって、(2)が後のIOTPメッセージにおける署名について確かめるのに計算に使用されて、要求は時間がある応答のない外では、(4)がIOTPなどの後のバージョンにおけるCustomer Careの役割に入力されるように使用したいくつかの場合で再送してください。 データがコピーされる方法はIOTP Transactionによります。 それがパーティーのどれかがそれに問い合わせることが望まれているとき、同じくらい長くその後、成功、失敗、またはcancelationにかかわらずトランザクションの終わりまでデータを保有しなければなりません。
Eastlake & Smith Standards Track [Page 3] RFC 2935 IOTP HTTP Supplement September 2000
イーストレークとスミスStandardsはIOTP HTTP補足2000年9月にRFC2935を追跡します[3ページ]。
The IOTP messages contain Net Locations (e.g. the PayReqNetLocn) which for HTTP will contain the URIs to which the IOTP client MUST send IOTP messages.
IOTPメッセージはHTTPがIOTPクライアントがそうしなければならないURIを含むのでメッセージをIOTPに送るネットLocations(例えば、PayReqNetLocn)を含んでいます。
Subsequent IOTP messages (XML documents) will be sent using the POST function of HTTP. The HTTP client MUST perform full HTTP POST requests.
その後のIOTPメッセージ(XMLドキュメント)にHTTPのポストの機能を使用させるでしょう。 HTTPクライアントは完全なHTTPポストの要求を実行しなければなりません。
The XML documents MUST be sent in a manner compatible with the external encodings allowed by the XML [XML] specification.
XML[XML]仕様で許容されている外部のencodingsとのコンパチブル方法でXMLドキュメントを送らなければなりません。
4.3 Stopping an IOTP Transaction
4.3 IOTPトランザクションを止めること。
The following should be read in conjunction with [RFC 2801].
以下は[RFC2801]に関連して読まれるべきです。
An IOTP Transaction is complete when
IOTP Transactionはいつを完成するかことです。
-- the IOTP client decides to fail the IOTP Transaction for some
reason either by canceling the transaction or as a result of
discovering an error in an IOTP message received, or
-- またはIOTPクライアントが、ある理由でトランザクションを取り消すか、IOTPメッセージにおける誤りが受信されたと発見することの結果、IOTP Transactionに失敗すると決める。
-- a "time out" occurs or a connection fails, e.g. a response to an
IOTP Message, has not been received after some user-defined period
of Time (including retransmissions).
-- 接続は失敗します、そして、「タイムアウト」が起こるか、または例えば、IOTP Messageへの応答はTimeのいつかのユーザによって定義された期間の後に受け取られていません(「再-トランスミッション」を含んでいて)。
An IOTP Client which processes an IOTP Transaction which:
IOTP Transactionを処理するIOTP Client、どれ、:
-- completes successfully (i.e. it has not received an Error Block
with a HardError or a Cancel Block) MUST direct the browser to the
Net Location specified in SuccessNetLocn in the Protocol Options
Component, i.e., cause it to do an HTTP GET with that URL.
-- 完成、首尾よく、すなわちプロトコルOptions ComponentのSuccessNetLocnで指定されたLocationがそれにそのURLでHTTP GETをさせるネットにブラウザを向けなければなりません(すなわち、それはHardErrorかキャンセルBlockと共にError Blockを受けていません)。
-- does not complete successfully, because it has received some Error
Trading Block, MUST display the information in the Error Message,
stop the transaction, and pass control to the browser so that it
will do a GET on the Error Net Location specified for the role
from which the error was received.
-- 誤りが受けられた役割に指定されたErrorネットLocationでGETをするようにブラウザにいくらかのError Trading Blockを受けて、Error Messageに情報を表示して、トランザクションを止めて、コントロールを渡さなければならないので、首尾よく完成しないでください。
-- is cancelled since a Cancel Block has been received, MUST stop the
IOTP Transaction and hand control to the browser so that it will
do a GET on the on the Cancel Net Location specified for the role
from which the Cancel Block was received.
-- キャンセルネットLocationがキャンセルBlockが受け取られた役割に指定したオンでGETをするように、キャンセルBlockを受け取ったので中止されて、IOTP Transactionを止めて、コントロールをブラウザに渡さなければなりません。
-- is in error because an IOTP Message does not conform to this
specification, MUST send an IOTP Message containing a Error
Trading Block to role from which the erroneous message was
received and the ErrorLogNetLoc specified for that role, stop the
-- IOTP Messageがこの仕様に従わないので間違って、誤ったメッセージが受け取られた役割にa Error Trading Blockを含むIOTP Messageとその役割、停止に指定されたErrorLogNetLocを送らなければなりません。
Eastlake & Smith Standards Track [Page 4] RFC 2935 IOTP HTTP Supplement September 2000
イーストレークとスミスStandardsはIOTP HTTP補足2000年9月にRFC2935を追跡します[4ページ]。
IOTP Transaction, and hand control to the browser so that it will
do a GET from the Error Net Location specified for the role from
which the bad message was received.
IOTP Transaction、悪いメッセージが受け取られた役割に指定されたErrorネットLocationからGETをするように、コントロールをブラウザに渡してください。
-- has a "time out", MUST display a message describing the time out.
May give the user the option of cancelling or retrying and/or may
automatically retry. On failure due to time out, treat as an
error above.
-- 「タイムアウト」を持って、タイムアウトについて説明するメッセージを表示しなければなりません。 取り消しか再試行のオプションをユーザに与えるかもしれない、そして/または、自動的に再試行するかもしれません。 タイムアウトによる失敗では、上の誤りとして扱ってください。
Each implementation of an IOTP client may decide whether or not to terminate the IOTP Client application immediately upon completing an IOTP Transaction or whether to wait until it is closed down as a result of, for example, user shut down or browser shut down.
IOTPクライアントの各実装は、すぐIOTP Transactionを完成するときのIOTP Clientアプリケーションを終えるかどうか、またはそれが例えば、ユーザ閉鎖かブラウザ閉鎖の結果、閉鎖されるまで待つかどうか決めるかもしれません。
5. Starting the Payment handler and Deliverer IOTP Servers
5. Payment操作者とDeliverer IOTP Serversを始動します。
Payment Handler and Deliverer IOTP Servers are started by receiving an IOTP Message which contains:
支払いHandlerとDeliverer IOTP Serversは、以下を含むIOTP Messageを受けることによって、始動されます。
-- for a Payment handler, a Payment Request Block, and
-- そしてPayment操作者、Payment Request Blockのために。
-- for a Delivery Handler, a Delivery Request Block
-- 配送操作者、配送要求ブロックに
6. Security Considerations
6. セキュリティ問題
Security of Internet Open Trade Protocol messages is primarily dependent on signatures within IOTP as described in [RFC 2801] and [RFC 2802]. Privacy protection for IOTP interactions can be obtained by using a secure channel for IOTP messages, such as SSL/TLS [RFC 2246].
インターネットオープンTradeプロトコルメッセージのセキュリティは[RFC2801]と[RFC2802]で説明されるように主としてIOTPの中の署名に依存しています。 IOTPメッセージに安全なチャンネルを使用することによって、IOTP相互作用のためのプライバシー保護を得ることができます、SSL/TLS[RFC2246]などのように。
Note that the security of payment protocols transported by IOTP is the responsibility of those payment protocols, NOT of IOTP.
IOTPによって輸送された支払いプロトコルのセキュリティがIOTPではなく、それらの支払いプロトコルの責任であることに注意してください。
7. IANA Considerations
7. IANA問題
This specification defines the APPLICATION/IOTP MIME type. The registration template is as follows [RFC 2048]:
この仕様はAPPLICATION/IOTP MIMEの種類を定義します。 登録テンプレートは以下の通りです[RFC2048]:
To: ietf-types@iana.org
To: ietf-types@iana.org
Subject: Registration of MIME media type APPLICATION/IOTP
Subject: MIMEメディアタイプAPPLICATION/IOTPの登録
MIME media type name: APPLICATION
MIMEメディア型名: アプリケーション
MIME subtype name: IOTP
MIME「副-タイプ」は以下を命名します。 IOTP
Required parameters: (none)
必要なパラメタ: (なにも)
Eastlake & Smith Standards Track [Page 5] RFC 2935 IOTP HTTP Supplement September 2000
イーストレークとスミスStandardsはIOTP HTTP補足2000年9月にRFC2935を追跡します[5ページ]。
Optional parameters: charset - see RFC 2376
任意のパラメタ: charset--RFC2376を見てください。
Encoding considerations: Content is XML and may in some cases
require quoted printable or base64 encoding. However, no encoding
is required for HTTP transport which is expected to be common.
問題をコード化します: 内容は、XMLであり、いくつかの場合、印刷可能であるかbase64の引用されたコード化を必要とするかもしれません。 しかしながら、コード化は一般的であると予想されるHTTP輸送に必要ではありません。
Security considerations: IOTP includes provisions for digital
authentication but for confidentiality, other mechanisms such as
TLS should be used. See RFC 2801 and RFC 2802.
セキュリティ問題: IOTPはデジタル認証のための条項を含んでいますが、秘密性のために、TLSなどの他のメカニズムは使用されるべきです。 RFC2801とRFC2802を見てください。
Interoperability considerations: See RFC 2801.
相互運用性問題: RFC2801を見てください。
Published specification: See RFC 2801 and RFC 2802.
広められた仕様: RFC2801とRFC2802を見てください。
Applications which use this media type: Internet Open Trading
Protocol applications.
このメディアタイプを使用するアプリケーション: インターネットオープンTradingプロトコルアプリケーション。
Additional information: (none)
追加情報: (なにも)
Person & email address to contact for further information:
Name: Donald E. Eastlake 3rd
Email: Donald.Eastlake@motorola.com
詳細のために連絡する人とEメールアドレス: 以下を命名してください。 ドナルドE.イーストレーク第3メール: Donald.Eastlake@motorola.com
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: IETF
コントローラを書くか、または変えてください: IETF
8. References
8. 参照
[RFC 1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945] バーナーズ・リー、T.、フィールディング、R.、およびH.Frystyk、「ハイパーテキストはプロトコルを移します--HTTP/1インチ、RFC1945、1996年5月。」
[RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedure", RFC 2048, November 1996.
解放された[RFC2048]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、RFC2048、1996年11月。
[RFC 2119] 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月。
[RFC 2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC 2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
July 1998.
[RFC2376] ホワイトヘッドとE.とM.ムラタ、「XMLメディアタイプ」、RFC2376、1998年7月。
[RFC 2396] Berners-Lee, T., Rielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2396] バーナーズ・リー、T.、Rielding、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
Eastlake & Smith Standards Track [Page 6] RFC 2935 IOTP HTTP Supplement September 2000
イーストレークとスミスStandardsはIOTP HTTP補足2000年9月にRFC2935を追跡します[6ページ]。
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP
Version 1.0", RFC 2801, April 2000.
バーデット、[RFC2801]D.、「インターネットの開いている取り引きプロトコル--、IOTP、バージョン1インチ、RFC2801、2000インチ年4月。
[RFC 2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for the
v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802,
April 2000
[RFC2802] ディヴィッドソンとK.とY.Kawatsura、「v1.0インターネットオープンTradingプロトコル(IOTP)のためのデジタルSignatures」、RFC2802、2000年4月
[XML] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible
Markup Language (XML) 1.0" <http://www.w3.org/TR/REC-xml>,
February 1998.
[XML]は、T.とパオリとJ.とC.Sperberg-マックィーン、「1インチの拡張マークアップ言語(XML)<http://www.w3.org/TR/REC-xml>、1998年2月」をいななかせます。
9. Authors' Addresses
9. 作者のアドレス
Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA
ドナルドE.イーストレーク第3モトローラ140の森林Avenue MA01749ハドソン(米国)
Phone: +1 978-562-2827(h)
+1 508-261-5434(w)
Fax: +1 508-261-4447(w)
EMail: Donald.Eastlake@motorola.com
以下に電話をしてください。 +1 978-562-2827(h)+1 508-261-5434(w)Fax: +1 508-261-4447 (w) メールしてください: Donald.Eastlake@motorola.com
Chris J. Smith Royal Bank of Canada 277 Front Street West Toronto, Ontario M5V 3A4 CANADA
クリスJ.スミスカナダ王立銀行277のフロント・ストリートのオンタリオの西M5V 3A4トロント(カナダ)
Phone: +1 416-348-6090 Fax: +1 416-348-2210 EMail: chris.smith@royalbank.com
以下に電話をしてください。 +1 416-348-6090Fax: +1 416-348-2210 メールしてください: chris.smith@royalbank.com
Eastlake & Smith Standards Track [Page 7] RFC 2935 IOTP HTTP Supplement September 2000
イーストレークとスミスStandardsはIOTP HTTP補足2000年9月にRFC2935を追跡します[7ページ]。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Eastlake & Smith Standards Track [Page 8]
イーストレークとスミス標準化過程[8ページ]
一覧
スポンサーリンク
