RFC2384 日本語訳
2384 POP URL Scheme. R. Gellens. August 1998. (Format: TXT=13649 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Gellens Request for Comments: 2384 QUALCOMM, Incorporated Category: Standards Track August 1998
Gellensがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2384年のクアルコム、法人組織のカテゴリ: 標準化過程1998年8月
POP URL Scheme
大衆的なURL体系
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
1. Introduction
1. 序論
[POP3] is a widely-deployed mail access protocol. Many programs access POP3 message stores, and thus need POP3 configuration information. Since there are multiple configuration elements which are required in order to access a mailbox, a single string representation is convenient.
[POP3]は広く配布しているメールアクセス・プロトコルです。 多くのプログラムが、POP3メッセージ店にアクセスして、その結果、POP3設定情報を必要とします。 メールボックスにアクセスするのに必要である複数の構成要素があるので、一連表現は便利です。
A POP3 mailbox (like an [IMAP4] mailbox) is a network resource, and URLs are a widely-supported generalized representation of network resources.
POP3メールボックス([IMAP4]メールボックスのような)はネットワーク資源です、そして、URLはネットワーク資源の広くサポートしている一般化された表現です。
A means of specifying a POP3 mailbox as a URL will likely be useful in many programs and protocols. [ACAP] is one case where a string encapsulation of elements required to access network services is needed. For example, an [IMAP4] message store is usually specified in ACAP datasets as an [IMAP-URL].
URLとしてPOP3メールボックスを指定する手段は多くのプログラムとプロトコルでおそらく役に立ちます。 [ACAP]は要素のカプセル化がネットワーク・サービスにアクセスするのを必要としたストリングが必要である1つのケースです。 例えば、通常、[IMAP4]メッセージ店がACAPデータセットで指定される、[IMAP-URL。]
This memo defines a URL scheme for referencing a POP mailbox.
このメモはPOPメールボックスに参照をつけることのURL体系を定義します。
2. Conventions Used in this Document
2. このDocumentのコンベンションUsed
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で定義されるように本書では解釈されることになっているべきです。
Gellens Standards Track [Page 1] RFC 2384 POP URL Scheme August 1998
Gellens標準化過程[1ページ]RFC2384はURL体系1998年8月に飛び出します。
3. POP Scheme
3. 体系を飛び出させてください。
The POP URL scheme designates a POP server, and optionally a port number, authentication mechanism, authentication ID, and/or authorization ID.
POP URL体系は任意にPOPサーバを指定します。ポートナンバー、認証機構、認証ID、そして/または、承認ID。
The POP URL follows the common Internet scheme syntax as defined in RFC 1738 [BASIC-URL] except that clear text passwords are not permitted. If :<port> is omitted, the port defaults to 110.
POP URLはクリアテキストパスワードが受入れられないのを除いて、RFC1738[BASIC URL]で定義されるように一般的なインターネット体系構文に従います。 : <ポート>が省略されるなら、ポートは110をデフォルトとします。
The POP URL is described using [ABNF] in Section 8.
POP URLは、セクション8で[ABNF]を使用することで説明されます。
A POP URL is of the general form:
POP URLは一般的なフォームのものです:
pop://<user>;auth=<auth>@<host>:<port>
://<ユーザ>を飛び出させてください; authは<auth>@<ホスト>: <ポート>と等しいです。
Where <user>, <host>, and <port> are as defined in RFC 1738, and some or all of the elements, except "pop://" and <host>, may be omitted.
要素の<ユーザ>、<ホスト>、および<ポート>がRFC1738で定義されるようにどこにあるか、そして、いくつかか「ポップス://」と<ホスト>以外のすべてが省略されるかもしれません。
4. POP User Name and Authentication Mechanism
4. ユーザ名と認証機構を飛び出させてください。
An authorization (which mailbox to access) and authentication (whose password to check against) identity (referred to as "user name" for simplicity) and/or authentication mechanism name may be supplied. These are used in a "USER", "APOP", "AUTH" [POP-AUTH], or extension command after making the connection to the POP server. If the URL doesn't supply an authentication identifier, the program interpreting the POP URL SHOULD request one from the user.
承認(アクセスへのどのメールボックス)と認証(チェックするパスワード)のアイデンティティ(簡単さのために「ユーザ名」と呼ばれる)、そして/または、認証機構名前を提供するかもしれないか。 接続を大衆的なサーバにした後に、これらは「ユーザ」、"APOP"、"AUTH"[大衆的なAUTH]、または拡大命令に使用されます。URLが認証識別子を提供しないなら、大衆的なURLを解釈するプログラムはユーザからの1つを要求するはずです。
An authentication mechanism can be expressed by adding ";AUTH=<enc- auth-type>" to the end of the user name. If the authentication mechanism name is not preceded by a "+", it is a SASL POP [SASL] mechanism. If it is preceded by a "+", it is either "APOP" or an extension mechanism.
「加えることによって、認証機構を表すことができる」; AUTHは<enc- auth-タイプ>と等しいです。」 ユーザ名の終わりまで。 「+」が認証機構名に先行しないなら、それはSASLの大衆的な[SASL]メカニズムです。 「+」がそれに先行するなら、それは、"APOP"か拡張機能のどちらかです。
When an <enc-auth-type> is specified, the client SHOULD request appropriate credentials from that mechanism and use the "AUTH", "APOP", or extension command instead of the "USER" command. If no user name is specified, one SHOULD be obtained from the mechanism or requested from the user as appropriate.
<enc-auth-タイプであるときに、>が指定されて、クライアントSHOULDはそのメカニズムから適切な資格証明書を要求して、「ユーザ」コマンドの代わりに"AUTH"、"APOP"、または拡大命令を使用します。 ユーザ名が全く指定されないなら、メカニズムから入手するか、またはユーザから適宜要求する1SHOULDです。
The string ";AUTH=*" indicates that the client SHOULD select an appropriate authentication mechanism. It MAY use any mechanism supported by the POP server.
AUTHは*と等しいです。「ストリング」; 」 クライアントが適切な認証機構を選択するべきであるのを示します。 それはPOPサーバによってサポートされたどんなメカニズムも使用するかもしれません。
If an <enc-auth-type> other than ";AUTH=*" is specified, the client SHOULD NOT use a different mechanism without explicit user permission.
「-<enc-authであるなら>をタイプしてください、」、;、AUTHが*と等しい 」、指定されていて、クライアントは明白なユーザ許可なしで異なったメカニズムを使用するべきではありません。
Gellens Standards Track [Page 2] RFC 2384 POP URL Scheme August 1998
Gellens標準化過程[2ページ]RFC2384はURL体系1998年8月に飛び出します。
If a user name is included with no authentication mechanism, then ";AUTH=*" is assumed.
「次に、ユーザ名が認証機構なしで含まれているなら」; AUTHは*と等しいです。」 想定されます。
Since URLs can easily come from untrusted sources, care must be taken when resolving a URL which requires or requests any sort of authentication. If authentication credentials are supplied to the wrong server, it may compromise the security of the user's account. The program resolving the URL should make sure it meets at least one of the following criteria in this case:
URLが信頼できないソースから容易に来ることができるので、どんな種類の認証も必要である、または要求するURLを決議するとき、注意しなければなりません。 認証資格証明書を間違ったサーバに供給するなら、それはユーザのアカウントのセキュリティに感染するかもしれません。 URLを決議するプログラムは、この場合少なくとも以下の評価基準の1つに会うのを確実にするはずです:
(1) The URL comes from a trusted source, such as a referral server which the client has validated and trusts according to site policy. Note that user entry of the URL may or may not count as a trusted source, depending on the experience level of the user and site policy.
(1) URLは信頼できるソースから来ます、サイト方針に従ったクライアントが有効にした紹介サーバや受託のように。 URLのユーザエントリーが信頼できるソースにみなすかもしれないことに注意してください、ユーザとサイト方針の経験レベルによって。
(2) Explicit local site policy permits the client to connect to the server in the URL. For example, if the client knows the site domain name, site policy may dictate that any hostname ending in that domain is trusted.
(2) 明白なローカル・サイト方針は、クライアントがURLでサーバに接続することを許可します。 例えば、クライアントがサイトドメイン名を知っているなら、サイト方針は、そのドメインのどんなホスト名結末も信じられると決めるかもしれません。
(3) The user confirms that connecting to that domain name with the specified credentials and/or mechanism is permitted.
(3) ユーザは、指定された資格証明書、そして/または、メカニズムでそのドメイン名に接続するのが受入れられると確認します。
(4) A mechanism is used which validates the server before passing potentially compromising client credentials.
(4) メカニズムは使用されています(潜在的に評判を落とすようなクライアント資格証明書を通過する前に、サーバを有効にします)。
(5) An authentication mechanism is used which will not reveal information to the server which could be used to compromise future connections.
(5) 認証機構は使用されています(今後の接続に感染するのに使用できたサーバに情報を明らかにしないでしょう)。
A URL containing ";AUTH=*" should be treated with extra care since it might fall back on a weaker security mechanism. Finally, clients are discouraged from using a plain text password as a fallback with ";AUTH=*" unless the connection has strong encryption (e.g., a key length of greater than 56 bits).
AUTHは*と等しいです。「URL含有」; 」 より弱いセキュリティー対策の上に後ろへ下がるかもしれないので、付加的な注意で扱われるべきです。 AUTHは*と等しいです。「最終的に、後退としてのプレーンテキストパスワードを使用する、クライアントが落胆している」 ; 」 接続に強い暗号化(例えば、56ビット以上のキー長)がない場合。
Note that if unsafe or reserved characters such as " " or ";" are present in the user name or authentication mechanism, they MUST be encoded as described in RFC 1738 [BASIC-URL].
または、危険であるならそれに注意するか、またはキャラクタを予約する、「「」、」、。 ユーザ名か認証機構に存在していて、RFC1738[BASIC URL]で説明されるようにそれらをコード化しなければなりません。
5. Relative POP URLs
5. 相対的な大衆的なURL
Relative POP URLs are not permitted.
相対的なPOP URLは受入れられません。
Gellens Standards Track [Page 3] RFC 2384 POP URL Scheme August 1998
Gellens標準化過程[3ページ]RFC2384はURL体系1998年8月に飛び出します。
6. Multinational Considerations
6. 多国籍の問題
Since 8-bit characters are not permitted in URLs, [UTF8] characters are encoded as required by the URL specification [BASIC-URL].
8ビットのキャラクタがURLで受入れられないので、URL仕様[BASIC URL]で[UTF8]キャラクタは必要に応じてコード化されます。
7. Examples
7. 例
The following examples demonstrate how a POP client program might translate various POP URLs into a series of POP commands. Commands sent from the client to the server are prefixed with "C:", and responses sent from the server to the client are prefixed with "S:".
以下の例はPOPクライアントプログラムがどう様々なPOP URLを一連のPOPコマンドに翻訳するかもしれないかを示します。 クライアントからサーバに送られたコマンドが前に置かれている、「C: 」 サーバからクライアントに送られた応答が前に置かれている、「S:」
The URL:
URL:
<pop://rg@mailsrv.qualcomm.com>
<ポップス: //rg@mailsrv.qualcomm.com 、gt。
Results in the following client commands:
以下のクライアントコマンドにおける結果:
<request password from user>
<connect to mailsrv.qualcomm.com, port 110>
S: +OK POP3 server ready <1896.697170952@mailsrv.qualcomm.com>
C: USER rg
S: +OK
C: PASS secret
S: +OK rg's mailbox has 2 messages (320 octets)
ユーザ><からの<要求パスワードはmailsrv.qualcomm.com、ポート110>Sに接続します: + OK POP3サーバ ready <1896.697170952@mailsrv.qualcomm.com 、gt;、C: USER rg S: + OK C: PASS秘密S: +OK rgのメールボックスには、2つのメッセージがあります。(320の八重奏)
The URL:
URL:
<pop://rg;AUTH=+APOP@mail.eudora.com:8110>
<ポップス://rg; AUTH=+ APOP@mail.eudora.com : 8110>。
Results in the following client commands:
以下のクライアントコマンドにおける結果:
<client requests password from user>
<connect to mail.eudora.com, port 8110>
S: +OK POP3 server ready <1896.697170952@mail.eudora.com>
C: APOP rg c4c9334bac560ecc979e58001b3e22fb
S: +OK mailbox has 1 message (369 octets)
ユーザ><からの要求パスワードがmail.eudora.com、ポート8110>Sに接続する<クライアント: + OK POP3サーバ ready <1896.697170952@mail.eudora.com 、gt;、C: APOP rg c4c9334bac560ecc979e58001b3e22fb S: + OKメールボックスには、1つのメッセージがあります。(369の八重奏)
The URL:
URL:
<pop://baz;AUTH=SCRAM-MD5@foo.bar>
<ポップス://baz; AUTH= SCRAM-MD5@foo.bar 、gt。
Results in the following client commands:
以下のクライアントコマンドにおける結果:
<connect to foo.bar, port 110>
<はfoo.bar、ポート110>に接続します。
S: +OK POP3 server ready <1896.697170952@foo.bar>
C: AUTH SCRAM-MD5 AGNocmlzADx0NG40UGFiOUhCMEFtL1FMWEI3MmVnQGVsZW
S: + OK POP3サーバ ready <1896.697170952@foo.bar 、gt;、C: AUTH、逃げる、-、MD5 AGNocmlzADx0NG40UGFiOUhCMEFtL1FMWEI3MmVnQGVsZW
Gellens Standards Track [Page 4] RFC 2384 POP URL Scheme August 1998
Gellens標準化過程[4ページ]RFC2384はURL体系1998年8月に飛び出します。
Fub3IuaW5ub3NvZnQuY29tPg==
S: + dGVzdHNhbHQBAAAAaW1hcEBlbGVhbm9yLmlubm9zb2Z0LmNvbQBq
aGNOWmxSdVBiemlGcCt2TFYrTkN3
C: AQAAAMg9jU8CeB4KOfk7sUhSQPs=
S: + U0odqYw3B7XIIW0oSz65OQ==
C:
S: +OK mailbox has 1 message (369 octets)
Fub3IuaW5ub3NvZnQuY29tPg== S: + dGVzdHNhbHQBAAAAaW1hcEBlbGVhbm9yLmlubm9zb2Z0LmNvbQBq aGNOWmxSdVBiemlGcCt2TFYrTkN3C: AQAAAMg9jU8CeB4KOfk7sUhSQPs= S: + U0odqYw3B7XIIW0oSz65OQ=C: S: + OKメールボックスには、1つのメッセージがあります。(369の八重奏)
8. ABNF for POP URL scheme
8. POP URL体系のためのABNF
The POP URL scheme is described using [ABNF]:
POP URL体系は[ABNF]を使用することで説明されます:
achar = uchar / "&" / "=" / "~"
; see [BASIC-URL] for "uchar" definition
acharはuchar/“&"/「=」/「~」と等しいです。 "uchar"定義に関して[BASIC URL]を見てください。
auth = ";AUTH=" ( "*" / enc-auth-type )
「auth=」 ; AUTH=、」(enc-auth「*」/タイプ)
enc-auth-type = enc-sasl / enc-ext
enc-auth-タイプはenc-sasl / enc-extと等しいです。
enc-ext = "+" ("APOP" / 1*achar)
;APOP or encoded extension mechanism name
enc-extは; 「+」 ("APOP"/1*achar)APOPかコード化された拡張機能名と等しいです。
enc-sasl = 1*achar
;encoded version of [SASL] "auth_type"
enc-saslは1*acharと等しいです; [SASL]「auth_タイプ」のバージョンをコード化します。
enc-user = 1*achar
;encoded version of [POP3] mailbox
enc-ユーザは1*acharと等しいです; [POP3]メールボックスのバージョンをコード化します。
pop-url = "pop://" server
大衆的なurlは「ポップス://」サーバと等しいです。
server = [user-auth "@"] hostport
;See [BASIC-URL] for "hostport" definition
サーバ=[ユーザ-auth"@"]hostport; "hostport"定義に関して見てください[基本的なURLの]。
user-auth = enc-user [auth]
ユーザ-authはenc-ユーザと等しいです。[auth]
9. Security Considerations
9. セキュリティ問題
Security considerations discussed in the [POP3] specification and the [BASIC-URL] specification are relevant. Security considerations related to authenticated URLs are discussed in section 4 of this document.
[POP3]仕様と[BASIC URL]仕様で議論したセキュリティ問題は関連しています。 このドキュメントのセクション4で認証されたURLに関連するセキュリティ問題について議論します。
Many email clients store the plain text password for later use after logging into a POP server. Such clients MUST NOT use a stored password in response to a POP URL without explicit permission from the user to supply that password to the specified host name.
POPサーバにログインした後に、多くのメールクライアントが後の使用のためのプレーンテキストパスワードを保存します。そのようなクライアントは、そのパスワードを指定されたホスト名に供給するのに明白な許可のないPOP URLに対応してユーザから保存されたパスワードを使用してはいけません。
Gellens Standards Track [Page 5] RFC 2384 POP URL Scheme August 1998
Gellens標準化過程[5ページ]RFC2384はURL体系1998年8月に飛び出します。
10. Acknowledgements
10. 承認
This document borrows heavily from Chris Newman's [IMAP-URL] specification, and has attempted to follow the advice in [URL- GUIDELINES].
このドキュメントは、クリス・ニューマン[IMAP-URL]の仕様から大いに借りて、[URL GUIDELINES]でのアドバイスに従うのを試みました。
11. References
11. 参照
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November
1997.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[ACAP] Newman, C., and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November
1997.
ニューマン、[ACAP]C.、J.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[BASIC-URL] Berners-Lee, T., Masinter, L., and M. McCahill,
"Uniform Resource Locators (URL)", RFC 1738,
December 1994.
1994年12月の[基本的なURL]のバーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」RFC1738。
[IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September
1997.
[IMAP-URL] ニューマン、C.、「IMAP URL体系」、RFC2192、1997年9月。
[IMAP4] Crispin, M., "Internet Message Access Protocol -
Version 4rev1", RFC 2060, December 1996.
[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
December 1994.
[POP-AUTH] マイアーズ、J.、「POP3 AUTHenticationコマンド」、RFC1734、1994年12月。
[POP3] Myers, J., and M. Rose, "Post Office Protocol --
Version 3", STD 53, RFC 1939, May 1996.
[POP3] マイアーズ、J.、およびM.ローズ、「バージョン3インチ、STD53、RFC1939、1996年POP--5月。」
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[URL-GUIDELINES] Masinter, Alvestrand, Zigmond, "Guidelines for new
URL Schemes", Work in Progress.
[URL-GUIDELINES] Masinter、Alvestrand、Zigmond、「新しいURL Schemesのためのガイドライン」、ProgressのWork。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[UTF8]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
Gellens Standards Track [Page 6] RFC 2384 POP URL Scheme August 1998
Gellens標準化過程[6ページ]RFC2384はURL体系1998年8月に飛び出します。
12. Author's Address
12. 作者のアドレス
Randall Gellens QUALCOMM, Incorporated 6455 Lusk Blvd. San Diego, CA 92121-2779 U.S.A.
ランドルGellensクアルコム、法人組織の6455年のラスクBlvd. サンディエゴ、カリフォルニア92121-2779米国
Phone: +1 619 651 5115 Fax: +1 619 651 5334 EMail: Randy@Qualcomm.Com
以下に電話をしてください。 +1 619 651、5115Fax: +1 5334年の619 651メール: Randy@Qualcomm.Com
Gellens Standards Track [Page 7] RFC 2384 POP URL Scheme August 1998
Gellens標準化過程[7ページ]RFC2384はURL体系1998年8月に飛び出します。
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Gellens Standards Track [Page 8]
Gellens標準化過程[8ページ]
一覧
スポンサーリンク
