RFC2891 日本語訳
2891 LDAP Control Extension for Server Side Sorting of Search Results.T. Howes, M. Wahl, A. Anantha. August 2000. (Format: TXT=15833 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Howes
Request for Comments: 2891 Loudcloud
Category: Standards Track M. Wahl
Sun Microsystems
A. Anantha
Microsoft
August 2000
コメントを求めるワーキンググループT.ハウズの要求をネットワークでつないでください: 2891年のLoudcloudカテゴリ: 標準化過程M.ウォールサン・マイクロシステムズA.Ananthaマイクロソフト2000年8月
LDAP Control Extension for Server Side Sorting of Search Results
検索結果のサーバサイドソーティングのためのLDAPコントロール拡張子
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
要約
This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. The controls may be useful when the LDAP client has limited functionality or for some other reason cannot sort the results but still needs them sorted. Other permissible controls on search operations are not defined in this extension.
このドキュメントは検索結果のサーバサイドソーティングのために2つのLDAPv3コントロール拡張子について説明します。 これらのコントロールで、クライアントはLDAP検索要求に結果を返すときサーバが使用するべきである属性タイプと合っている規則を指定できます。 ある他の理由が、LDAPクライアントが機能性を制限したか、結果を分類できませんが、またはまだそれらを分類する必要があるので、コントロールは役に立つかもしれません。 索敵行動の他の許されているコントロールはこの拡大で定義されません。
The sort controls allow a server to return a result code for the sorting of the results that is independent of the result code returned for the search operation.
種類のコントロールで、サーバは結果の索敵行動のために返された結果コードから独立しているソーティングのために結果コードを返すことができます。
The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97].
“MUST"、“SHOULD"、および「5月」が本書では使用したキーワードは[bradner97]で説明されるように解釈されることです。
Howes, et al. Standards Track [Page 1] RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
ハウズ、他 標準化過程[1ページ]RFC2891LDAPは2000年8月にサーバサイドソーティングのための拡大を制御します。
1. The Controls
1. コントロール
1.1 Request Control
1.1 要求コントロール
This control is included in the searchRequest message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3].
このコントロールはLDAPMessageのコントロール分野の一部としてsearchRequestメッセージに含まれています、.12セクション4.1[LDAPv3]で定義されるように。
The controlType is set to "1.2.840.113556.1.4.473". The criticality MAY be either TRUE or FALSE (where absent is also equivalent to FALSE) at the client's option. The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE:
controlTypeが用意ができている、「1.2 .840 .113556 .1 .4 0.473インチ」 また、休むのは、そうです。臨界がTRUEかFALSEのどちらかであるかもしれない、(どこ、FALSEと同等物) クライアントの選択で。 controlValueは値が以下のSEQUENCEの価値のBERコード化であるOCTET STRINGです:
SortKeyList ::= SEQUENCE OF SEQUENCE {
attributeType AttributeDescription,
orderingRule [0] MatchingRuleId OPTIONAL,
reverseOrder [1] BOOLEAN DEFAULT FALSE }
SortKeyList:、:= 系列の系列attributeType AttributeDescription、任意のorderingRule[0]MatchingRuleId reverseOrder[1]論理演算子は虚偽でデフォルトとします。
The SortKeyList sequence is in order of highest to lowest sort key precedence.
SortKeyList系列が最も低い分類用キー先行に最も高いことの順にあります。
The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD be one that is valid for the attribute type it applies to. If it is not, the server will return inappropriateMatching.
中で定義されるように4.1に.9[LDAPv3]を区分してください、SHOULD。MatchingRuleId、それが申し込む属性タイプにとって、有効なものになってください。 それがそうでないなら、サーバはinappropriateMatchingを返すでしょう。
Each attributeType should only occur in the SortKeyList once. If an attributeType is included in the sort key list multiple times, the server should return an error in the sortResult of unwillingToPerform.
各attributeTypeはSortKeyListに一度起こるだけであるはずです。 attributeTypeが分類用キーリストに複数の回含まれているなら、サーバはunwillingToPerformのsortResultで誤りを返すべきです。
If the orderingRule is omitted, the ordering MatchingRule defined for use with this attribute MUST be used.
orderingRuleが省略されるなら、MatchingRuleが使用のためにこの属性で定義した注文を使用しなければなりません。
Any conformant implementation of this control MUST allow a sort key list with at least one key.
このコントロールのどんなconformant実装も少なくとも1個のキーで分類用キーリストを許容しなければなりません。
1.2 Response Control
1.2 応答制御
This control is included in the searchResultDone message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3].
このコントロールはLDAPMessageのコントロール分野の一部としてsearchResultDoneメッセージに含まれています、.12セクション4.1[LDAPv3]で定義されるように。
The controlType is set to "1.2.840.113556.1.4.474". The criticality is FALSE (MAY be absent). The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE:
controlTypeが用意ができている、「1.2 .840 .113556 .1 .4 0.474インチ」 臨界はFALSE(休むかもしれない)です。 controlValueは値が以下のSEQUENCEの価値のBERコード化であるOCTET STRINGです:
Howes, et al. Standards Track [Page 2] RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
ハウズ、他 標準化過程[2ページ]RFC2891LDAPは2000年8月にサーバサイドソーティングのための拡大を制御します。
SortResult ::= SEQUENCE {
sortResult ENUMERATED {
success (0), -- results are sorted
operationsError (1), -- server internal failure
timeLimitExceeded (3), -- timelimit reached before
-- sorting was completed
strongAuthRequired (8), -- refused to return sorted
-- results via insecure
-- protocol
adminLimitExceeded (11), -- too many matching entries
-- for the server to sort
noSuchAttribute (16), -- unrecognized attribute
-- type in sort key
inappropriateMatching (18), -- unrecognized or
-- inappropriate matching
-- rule in sort key
insufficientAccessRights (50), -- refused to return sorted
-- results to this client
busy (51), -- too busy to process
unwillingToPerform (53), -- unable to sort
other (80)
},
attributeType [0] AttributeDescription OPTIONAL }
SortResult:、:= 系列{ 数え上げられたsortResult; サーバがnoSuchAttribute(16)を分類するように、結果は分類されたoperationsError(1)です--サーバの内部の失敗timeLimitExceeded(3)--以前達したtimelimit--ソーティングが完成したstrongAuthRequired(8)であったという(0)が返すのを拒否した成功はプロトコルadminLimitExceeded(11)(あまりに多くの合っているエントリー)を分類しました(不安定を通した結果); --認識されていない属性--分類用キーinappropriateMatching(18)をタイプしてください--、認識されていなさ、このクライアントへの--リターンに分類されて、拒否された不適当なマッチング(分類用キーinsufficientAccessRights(50)の規則)--結果は他の(80)を分類できないunwillingToPerform(53)を処理できないくらい忙しい(51)と忙しくします; attributeType0AttributeDescription任意です; }
2. Client-Server Interaction
2. クライアント/サーバ相互作用
The sortKeyRequestControl specifies one or more attribute types and matching rules for the results returned by a search request. The server SHOULD return all results for the search request in the order specified by the sort keys. If the reverseOrder field is set to TRUE, then the entries will be presented in reverse sorted order for the specified key.
sortKeyRequestControlは1つ以上の属性タイプと合っている規則を検索要求で返された結果に指定します。 サーバSHOULDは分類用キーによって指定されたオーダーにおける検索要求のためにすべての結果を返します。 reverseOrder分野がTRUEに設定されると、エントリーは指定されたキーの逆の分類された注文に示されるでしょう。
There are six possible scenarios that may occur as a result of the sort control being included on the search request:
検索要求のときに含まれている種類のコントロールの結果、起こるかもしれない6つの可能なシナリオがあります:
1 - If the server does not support this sorting control and the
client specified TRUE for the control's criticality field, then
the server MUST return unavailableCriticalExtension as a return
code in the searchResultDone message and not send back any other
results. This behavior is specified in section 4.1.12 of
[LDAPv3].
1--サーバが、このソーティングがコントロールであるとサポートしないで、クライアントがコントロールの臨界分野にTRUEを指定したなら、サーバは、searchResultDoneメッセージの復帰コードとしてunavailableCriticalExtensionを返して、いかなる他の結果も返送してはいけません。 この振舞いは.12セクション4.1[LDAPv3]で指定されます。
2 - If the server does not support this sorting control and the
client specified FALSE for the control's criticality field, then
the server MUST ignore the sort control and process the search
request as if it were not present. This behavior is specified in
section 4.1.12 of [LDAPv3].
2--サーバが、このソーティングがコントロールであるとサポートしないで、クライアントがコントロールの臨界分野にFALSEを指定したなら、まるでそれが存在していないかのように、サーバは、種類のコントロールを無視して、検索要求を処理しなければなりません。 この振舞いは.12セクション4.1[LDAPv3]で指定されます。
Howes, et al. Standards Track [Page 3] RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
ハウズ、他 標準化過程[3ページ]RFC2891LDAPは2000年8月にサーバサイドソーティングのための拡大を制御します。
3 - If the server supports this sorting control but for some reason
cannot sort the search results using the specified sort keys and
the client specified TRUE for the control's criticality field,
then the server SHOULD do the following: return
unavailableCriticalExtension as a return code in the
searchResultDone message; include the sortKeyResponseControl in
the searchResultDone message, and not send back any search result
entries.
3--サーバがコントロールの臨界分野に指定された分類用キーとクライアントの指定されたTRUEを使用することでこのソーティングがコントロールであるとサポートしますが、ある理由で検索結果を分類できないなら、サーバSHOULDは以下をします: searchResultDoneメッセージの復帰コードとしてunavailableCriticalExtensionを返してください。 中のsearchResultDoneが通信して、少しの検索結果エントリーも返送しないsortKeyResponseControlを含めてください。
4 - If the server supports this sorting control but for some reason
cannot sort the search results using the specified sort keys and
the client specified FALSE for the control's criticality field,
then the server should return all search results unsorted and
include the sortKeyResponseControl in the searchResultDone
message.
4--サーバがコントロールの臨界分野に指定された分類用キーとクライアントの指定されたFALSEを使用することでこのソーティングがコントロールであるとサポートしますが、ある理由で検索結果を分類できないなら、サーバはsearchResultDoneメッセージで結果が非分類して、含むすべての検索にsortKeyResponseControlを返すべきです。
5 - If the server supports this sorting control and can sort the
search results using the specified sort keys, then it should
include the sortKeyResponseControl in the searchResultDone
message with a sortResult of success.
5--サーバが指定された分類用キーを使用することでこのソーティングがコントロールであるとサポートして、検索結果を分類できるなら、それは成功のsortResultと共にsearchResultDoneメッセージにsortKeyResponseControlを含むべきです。
6 - If the search request failed for any reason and/or there are no
searchResultEntry messages returned for the search response, then
the server SHOULD omit the sortKeyResponseControl from the
searchResultDone message.
6--検索要求がいずれかのために失敗したなら、検索応答のために返されたsearchResultEntryメッセージは、全く推論する、そして/または、なくて、次に、サーバSHOULDはsearchResultDoneメッセージからsortKeyResponseControlを省略します。
The client application is assured that the results are sorted in the specified key order if and only if the result code in the sortKeyResponseControl is success. If the server omits the sortKeyResponseControl from the searchResultDone message, the client SHOULD assume that the sort control was ignored by the server.
クライアントアプリケーションが結果が指定された主要なオーダーで分類されることが保証される、sortKeyResponseControlの結果コードである場合にだけ、成功はそうです。 サーバがsearchResultDoneメッセージからsortKeyResponseControlを省略するなら、クライアントSHOULDは、種類のコントロールがサーバによって無視されたと仮定します。
The sortKeyResponseControl, if included by the server in the searchResultDone message, should have the sortResult set to either success if the results were sorted in accordance with the keys specified in the sortKeyRequestControl or set to the appropriate error code as to why it could not sort the data (such as noSuchAttribute or inappropriateMatching). Optionally, the server MAY set the attributeType to the first attribute type specified in the SortKeyList that was in error. The client SHOULD ignore the attributeType field if the sortResult is success.
searchResultDoneメッセージのサーバによって含まれているなら、結果がそれがデータ(noSuchAttributeかinappropriateMatchingなどの)を分類できなかった理由に関してsortKeyRequestControlで指定されたキーに従って分類されたか、または適切なエラーコードにセットするなら、sortKeyResponseControlはsortResultを成功に用意ができさせるでしょうに。 任意に、サーバは間違ったSortKeyListで指定された最初の属性タイプにattributeTypeを設定するかもしれません。 クライアントSHOULDはsortResultが成功であるならattributeType分野を無視します。
The server may not be able to sort the results using the specified sort keys because it may not recognize one of the attribute types, the matching rule associated with an attribute type is not applicable, or none of the attributes in the search response are of these types. Servers may also restrict the number of keys allowed in the control, such as only supporting a single key.
サーバが属性タイプのひとりを認識しないかもしれないので指定された分類用キーを使用することで結果を分類できないかもしれない、属性タイプに関連している合っている規則が適切でないか、またはこれらのタイプには検索応答における属性のいずれもありません。 また、サーバはコントロールで許容された単一のキーを支えなどなどのだけキーの数を制限するかもしれません。
Howes, et al. Standards Track [Page 4] RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
ハウズ、他 標準化過程[4ページ]RFC2891LDAPは2000年8月にサーバサイドソーティングのための拡大を制御します。
Servers that chain requests to other LDAP servers should ensure that the server satisfying the client's request sort the entire result set prior to sending back the results.
他のLDAPサーバに要求を束縛するサーバは、結果を返送する前にクライアントの要望に応じるサーバが全体の結果セットを分類するのを確実にするべきです。
2.1 Behavior in a chained environment
2.1 チェーニングされた環境における振舞い
If a server receives a sort request, the client expects to receive a set of sorted results. If a client submits a sort request to a server which chains the request and gets entries from multiple servers, and the client has set the criticality of the sort extension to TRUE, the server MUST merge sort the results before returning them to the client or MUST return unwillingToPerform.
サーバが種類の要求を受け取るなら、クライアントは、1セットの分類された結果を受けると予想します。 クライアントが要求をチェーニングして、複数のサーバから入国許可を得るサーバに種類の要求を提出して、クライアントが種類の拡大の臨界をTRUEに設定したなら、サーバは種類を合併しなければなりません。それらをクライアントに返さなければならないか、またはリターンunwillingToPerformを返さなければならない前の結果。
2.2 Other sort issues
2.2 他の種類の問題
An entry that meets the search criteria may be missing one or more of the sort keys. In that case, the entry is considered to have a value of NULL for that key. This standard considers NULL to be a larger value than all other valid values for that key. For example, if only one key is specified, entries which meet the search criteria but do not have that key collate after all the entries which do have that key. If the reverseOrder flag is set, and only one key is specified, entries which meet the search criteria but do not have that key collate BEFORE all the entries which do have that key.
検索評価基準を満たすエントリーは分類用キーのなくなった1つ以上であるかもしれません。 その場合、エントリーにはそのキーのためのNULLの値があると考えられます。 この規格は、NULLがそのキーのための他のすべての有効値より大きい値であると考えます。 例えば、1個のキーが指定されます、検索評価基準を満たしますが、そのキーが結局そのキーを持っているエントリーを照合しないエントリーならばさえ、よかったでしょう。 旗はreverseOrderであるなら設定されます、そして、1個のキーだけが指定されます、検索評価基準を満たしますが、そのキーがBEFOREを照合しないエントリー。そのキーがあるすべてのエントリー。
If a sort key is a multi-valued attribute, and an entry happens to have multiple values for that attribute and no other controls are present that affect the sorting order, then the server SHOULD use the least value (according to the ORDERING rule for that attribute).
分類用キーがマルチ評価された属性であり、エントリーにはその属性のための複数の値がたまたまあって、他のどんなコントロールもソーティング命令に影響するプレゼント、次に、サーバSHOULDが最少の値(その属性のためのORDERING規則に従って)を使用するということでないなら。
3. Interaction with other search controls
3. 他の検索コントロールとの相互作用
When the sortKeyRequestControl control is included with the pagedResultsControl control as specified in [LdapPaged], then the server should send the searchResultEntry messages sorted according to the sort keys applied to the entire result set. The server should not simply sort each page, as this will give erroneous results to the client.
指定されるとしてのpagedResultsControlコントロールが[LdapPaged]にある状態でsortKeyRequestControlコントロールが含まれていると、サーバは全体の結果セットに適用された分類用キーに従って分類されたsearchResultEntryメッセージを送るべきです。 これが誤った結果をクライアントに与えるとき、サーバは各ページを絶対に分類するべきではありません。
The sortKeyList must be present on each searchRequest message for the paged result. It also must not change between searchRequests for the same result set. If the server has sorted the data, then it SHOULD send back a sortKeyResponseControl control on every searchResultDone message for each page. This will allow clients to quickly determine if the result set is sorted, rather than waiting to receive the entire result set.
sortKeyListは呼び出された結果へのそれぞれのsearchRequestメッセージに存在していなければなりません。 また、それは同じ結果セットのためにsearchRequestsの間で変化してはいけません。 サーバはデータを分類して、次に、それはSHOULDです。各ページへのあらゆるsearchResultDoneメッセージでsortKeyResponseControlコントロールを返送してください。 これで、クライアントは、全体の結果セットを受け取るのを待っているより結果セットがむしろ分類されるかどうかとすぐに決心できるでしょう。
Howes, et al. Standards Track [Page 5] RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
ハウズ、他 標準化過程[5ページ]RFC2891LDAPは2000年8月にサーバサイドソーティングのための拡大を制御します。
4. Security Considerations
4. セキュリティ問題
Implementors and administrators should be aware that allowing sorting of results could enable the retrieval of a large number of records from a given directory service, regardless of administrative limits set on the maximum number of records to return.
作成者と管理者は許容して、結果のソーティングが与えられたディレクトリサービスからの多くの記録の検索を可能にするかもしれないのを意識しているべきです、返す記録の最大数に設定された管理限界にかかわらず。
A client that desired to pull all records out of a directory service could use a combination of sorting and updating of search filters to retrieve all records in a database in small result sets, thus circumventing administrative limits.
すべての記録をディレクトリサービスから取り出すことを望んでいたクライアントは小さい結果セットでデータベースでのすべての記録を検索するのにソーティングの組み合わせと検索フィルタのアップデートを使用できました、その結果、管理限界を回避します。
This behavior can be overcome by the judicious use of permissions on the directory entries by the administrator and by intelligent implementations of administrative limits on the number of records retrieved by a client.
管理者と知的な実装によるディレクトリエントリーのクライアントによって検索された記録の数における許容の管理限界の賢明な使用でこの振舞いに打ち勝つことができます。
5. References
5. 参照
[LDAPv3] Wahl, M, Kille, S. and T. Howes, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[LDAPv3]ウォールとMとKilleとS.とT.ハウズ、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のための主要なワーズ」、BCP14、RFC2119、1997年3月。
[LdapPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP
Control Extension for Simple Paged Results Manipulation",
RFC 2696, September 1999.
[LdapPaged] ワイダー、C.、ハーロン、A.、Anantha、A.、およびT.ハウズ、「LDAPは簡単な呼び出された結果操作のための拡大を制御します」、RFC2696、1999年9月。
Howes, et al. Standards Track [Page 6] RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
ハウズ、他 標準化過程[6ページ]RFC2891LDAPは2000年8月にサーバサイドソーティングのための拡大を制御します。
6. Authors' Addresses
6. 作者のアドレス
Anoop Anantha Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA
Anoop Anantha Microsoft Corp.1マイクロソフト、道のワシントン98052レッドモンド(米国)
Phone: +1 425 882-8080 EMail: anoopa@microsoft.com
以下に電話をしてください。 +1 425 882-8080 メールしてください: anoopa@microsoft.com
Tim Howes Loudcloud, Inc. 615 Tasman Dr. Sunnyvale, CA 94089 USA
ティムハウズLoudcloud Inc.615タスマンサニーベル博士、カリフォルニア94089米国
EMail: howes@loudcloud.com
メール: howes@loudcloud.com
Mark Wahl Sun Microsystems, Inc. 8911 Capital of Texas Hwy Suite 4140 Austin, TX 78759 USA
4140年のテキサスHwyスイートテキサス78759オースチン(米国)のマークウォールサン・マイクロシステムズ・インク8911首都
EMail: Mark.Wahl@sun.com
メール: Mark.Wahl@sun.com
Howes, et al. Standards Track [Page 7] RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
ハウズ、他 標準化過程[7ページ]RFC2891LDAPは2000年8月にサーバサイドソーティングのための拡大を制御します。
7. Full Copyright Statement
7. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Howes, et al. Standards Track [Page 8]
ハウズ、他 標準化過程[8ページ]
一覧
スポンサーリンク
