Network Working Group M. Crispin
Request for Comments: 4315 December 2005
Obsoletes: 2359
Category: Standards Track
Internet Message Access Protocol (IMAP) - UIDPLUS extension
Status of This 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients.
インターネットメッセージアクセスプロトコル（IMAP）のUIDPLUS拡張は、いくつかのクライアント操作で使用される時間とリソースの量を低減することを目的と機能セットを提供します。 UIDPLUSの機能は、主に非接続使用のクライアントのために意図されています。
The UIDPLUS extension is present in any IMAP server implementation that returns "UIDPLUS" as one of the supported capabilities to the CAPABILITY command.
UIDPLUS拡張は、CAPABILITYコマンドでサポートしている能力の一つとして「UIDPLUS」を返す任意のIMAPサーバの実装に存在しています。
The UIDPLUS extension defines an additional command. In addition, this document recommends new status response codes in IMAP that SHOULD be returned by all server implementations, regardless of whether or not the UIDPLUS extension is implemented.
UIDPLUS拡張は、追加のコマンドを定義します。また、この文書は関係なく、UIDPLUS拡張が実装されているかどうかにかかわらず、すべてのサーバの実装によって返されるべきでIMAPの新しいステータス応答コードを推奨しています。
The added facilities of the features in UIDPLUS are optimizations; clients can provide equivalent functionality, albeit less efficiently, by using facilities in the base protocol.
UIDPLUSの機能の追加設備が最適化されています。クライアントは、基本プロトコルの施設を使用することにより、低い効率ではあるが、同等の機能を提供することができます。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
実施例において、「C：」および「S：」は、それぞれ、クライアントとサーバによって送信されたラインを示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHALL NOT"、 "SHOULD"、この文書では、 "べきではない" "MAY"、および "任意の" と解釈されるべきです[KEYWORDS]で説明。
A "UID set" is similar to the [IMAP] sequence set; however, the "*" value for a sequence number is not permitted.
「UIDセット」セット[IMAP]配列と類似しています。しかし、シーケンス番号のための「*」値が許可されていません。
The following command definition is an extension to [IMAP] section 6.4.
以下のコマンド定義は、[IMAP]セクション6.4に拡張したものです。
Arguments: sequence set
引数：シーケンスセット
Data: untagged responses: EXPUNGE
データ：タグなし応答：EXPUNGE
Result: OK - expunge completed NO - expunge failure (e.g., permission denied) BAD - command unknown or arguments invalid
結果：OK - 完了NOを抹消 - 失敗を抹消（例えば、許可が拒否された）BAD - 無効なコマンド不明または引数
The UID EXPUNGE command permanently removes all messages that both have the \Deleted flag set and have a UID that is included in the specified sequence set from the currently selected mailbox. If a message either does not have the \Deleted flag set or has a UID that is not included in the specified sequence set, it is not affected.
UID EXPUNGEコマンドは永久に両方が\ Deletedフラグがセットされているし、現在選択されているメールボックスから設定された所定のシーケンスに含まれるUIDを持っているすべてのメッセージを削除します。メッセージが\ Deletedフラグがセットされているか、指定されたシーケンスセットに含まれていないUIDを持っていないか場合は、それが影響を受けません。
This command is particularly useful for disconnected use clients. By using UID EXPUNGE instead of EXPUNGE when resynchronizing with the server, the client can ensure that it does not inadvertantly remove any messages that have been marked as \Deleted by other clients between the time that the client was last connected and the time the client resynchronizes.
このコマンドは、切断に使用するクライアントのために特に有用です。サーバと再同期するときの代わりにEXPUNGEのUID EXPUNGEを使用することにより、クライアントは、それが不注意クライアントが接続されている最後だった時間は、クライアントが再同期化する時間の間に他のクライアントによって削除\としてマークされたすべてのメッセージを削除しないことを確実にすることができます。
If the server does not support the UIDPLUS capability, the client should fall back to using the STORE command to temporarily remove the \Deleted flag from messages it does not want to remove, then issuing the EXPUNGE command. Finally, the client should use the STORE command to restore the \Deleted flag on the messages in which it was temporarily removed.
サーバがUIDPLUS機能をサポートしていない場合、クライアントは一時的に、それはその後、EXPUNGEコマンドを発行し、削除したくないメッセージから\ Deletedフラグを削除するにはSTOREコマンドを使用してにフォールバックする必要があります。最後に、クライアントは、それが一時的に削除されたメッセージに、\ Deletedフラグを復元するために、STOREコマンドを使用する必要があります。
Alternatively, the client may fall back to using just the EXPUNGE command, risking the unintended removal of some messages.
また、クライアントは、いくつかのメッセージの意図しない除去を危険にさらし、ちょうどEXPUNGEコマンドを使用してにフォールバックします。
Example: C: A003 UID EXPUNGE 3000:3002 S: * 3 EXPUNGE S: * 3 EXPUNGE S: * 3 EXPUNGE S: A003 OK UID EXPUNGE completed
例：C：A003 UID EXPUNGE 3000：3002 S：* 3 EXPUNGE S：* 3 EXPUNGEのS：* 3 EXPUNGE S：A003 OK UID EXPUNGEが完成
The following response codes are extensions to the response codes defined in [IMAP] section 7.1. With limited exceptions, discussed below, server implementations that advertise the UIDPLUS extension SHOULD return these response codes.
次のレスポンスコードは、[IMAP]セクション7.1で定義された応答コードの拡張です。以下で説明する限定的な例外、と、UIDPLUS拡張子を広告サーバーの実装は、これらの応答コードを返すべきです。
In the case of a mailbox that has permissions set so that the client can COPY or APPEND to the mailbox, but not SELECT or EXAMINE it, the server SHOULD NOT send an APPENDUID or COPYUID response code as it would disclose information about the mailbox.
それはメールボックスに関する情報を開示すると同じように、クライアントがSELECTまたはそれを調べてコピーしたり、メールボックスにAPPENDが、できないように設定された権限を持つメールボックスの場合は、サーバーはAPPENDUIDまたはCOPYUID応答コードを送るべきではありません。
In the case of a mailbox that has UIDNOTSTICKY status (as defined below), the server MAY omit the APPENDUID or COPYUID response code as it is not meaningful.
それは意味がないように（以下に定義）UIDNOTSTICKYステータスを持つメールボックスの場合、サーバはAPPENDUID又はCOPYUID応答コードを省略することができます。
If the server does not return the APPENDUID or COPYUID response codes, the client can discover this information by selecting the destination mailbox. The location of messages placed in the destination mailbox by COPY or APPEND can be determined by using FETCH and/or SEARCH commands (e.g., for Message-ID or some unique marker placed in the message in an APPEND).
サーバがAPPENDUIDまたはCOPYUID応答コードを返さない場合、クライアントは、送信先のメールボックスを選択することで、この情報を発見することができます。 COPYまたはAPPENDによって宛先メールボックスに置かれたメッセージの位置はFETCHおよび/または検索コマンド（例えば、メッセージID、またはAPPENDにメッセージに入れいくつかのユニークなマーカーについて）を用いて決定することができます。
APPENDUID
APPENDUID
Followed by the UIDVALIDITY of the destination mailbox and the UID assigned to the appended message in the destination mailbox, indicates that the message has been appended to the destination mailbox with that UID.
宛先メールボックスと宛先メールボックスに添付メッセージに割り当てられたUIDのUIDVALIDITY続いて、メッセージは、そのUIDと宛先のメールボックスに追加されたことを示します。
If the server also supports the [MULTIAPPEND] extension, and if multiple messages were appended in the APPEND command, then the second value is a UID set containing the UIDs assigned to the appended messages, in the order they were transmitted in the APPEND command. This UID set may not contain extraneous UIDs or the symbol "*".
サーバはまた、[MULTIAPPEND]拡張をサポートし、複数のメッセージがAPPENDコマンドに付加された場合、第2の値は、それらがAPPENDコマンドで送信された順に添付メッセージに割り当てられたUIDを含むUID設定されている場合。このUIDセットは無関係なのUIDまたはシンボル「*」を含めることはできません。
Note: the UID set form of the APPENDUID response code MUST NOT be used if only a single message was appended. In particular, a server MUST NOT send a range such as 123:123. This is because a client that does not support [MULTIAPPEND] expects only a single UID and not a UID set.
注：単一のメッセージに添付された場合APPENDUID応答コードのUID・セット・フォームを使用してはいけません。 123：具体的には、サーバーは、123のように範囲を送ってはいけません。 [MULTIAPPEND]サポートしていないクライアントは、UIDのセットのみ、単一のUIDとないを期待するためです。
UIDs are assigned in strictly ascending order in the mailbox (refer to [IMAP], section 2.3.1.1) and UID ranges are as in [IMAP]; in particular, note that a range of 12:10 is exactly equivalent to 10:12 and refers to the sequence 10,11,12.
UIDを厳密に（[IMAP]、セクション2.3.1.1を参照）とUID範囲は[IMAP]のようにしているメールボックスに昇順に割り当てられます。特に、12：10の範囲は、10：12に正確に相当し、配列10,11,12をいいます。
This response code is returned in a tagged OK response to the APPEND command.
この応答コードは、APPENDコマンドへのタグ付けされたOK応答で返されます。
COPYUID
COPYUID
Followed by the UIDVALIDITY of the destination mailbox, a UID set containing the UIDs of the message(s) in the source mailbox that were copied to the destination mailbox and containing the UIDs assigned to the copied message(s) in the destination mailbox, indicates that the message(s) have been copied to the destination mailbox with the stated UID(s).
宛先メールボックスのUIDVALIDITY続いて、宛先のメールボックスにコピーされた元のメールボックス内のメッセージ（単数または複数）のUIDを含み、宛先のメールボックスにコピーされたメッセージ（単数または複数）に割り当てられたUIDを含むUIDセットは、示しメッセージ（単数または複数）が述べUID（S）と宛先のメールボックスにコピーされていること。
The source UID set is in the order the message(s) were copied; the destination UID set corresponds to the source UID set and is in the same order. Neither of the UID sets may contain extraneous UIDs or the symbol "*".
ソースUIDセットは、メッセージ（単数または複数）はコピーされたためです。宛先UIDのセットは、ソースUIDセットに対応し、同じ順序です。 UIDのセットのどちらも不要なのUIDまたはシンボル「*」が含まれていてもよいです。
UIDs are assigned in strictly ascending order in the mailbox (refer to [IMAP], section 2.3.1.1) and UID ranges are as in [IMAP]; in particular, note that a range of 12:10 is exactly equivalent to 10:12 and refers to the sequence 10,11,12.
UIDを厳密に（[IMAP]、セクション2.3.1.1を参照）とUID範囲は[IMAP]のようにしているメールボックスに昇順に割り当てられます。特に、12：10の範囲は、10：12に正確に相当し、配列10,11,12をいいます。
This response code is returned in a tagged OK response to the COPY command.
この応答コードは、COPYコマンドへのタグ付けされたOK応答で返されます。
UIDNOTSTICKY
UIDNOTSTICKY
The selected mailbox is supported by a mail store that does not support persistent UIDs; that is, UIDVALIDITY will be different each time the mailbox is selected. Consequently, APPEND or COPY to this mailbox will not return an APPENDUID or COPYUID response code.
選択したメールボックスは、永続的なUIDをサポートしていないメールストアによってサポートされています。つまり、UIDVALIDITYは、メールボックスが選択されるたびに異なります。その結果、APPENDまたはAPPENDUIDまたはCOPYUID応答コードを返さないこのメールボックスにコピーします。
This response code is returned in an untagged NO response to the SELECT command.
この応答コードは、SELECTコマンドにタグなしNO応答で返されます。
Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores. This facility exists to support legacy mail stores in which it is technically infeasible to support persistent UIDs. This should be avoided when designing new mail stores.
注意：サーバは任意のUIDNOTSTICKYのメールストアを持つべきではありません。この機能は、永続的なUIDをサポートするために、技術的に実行不可能である従来のメールストアをサポートするために存在しています。新しいメールストアを設計するとき、これは避けるべきです。
Example: C: A003 APPEND saved-messages (\Seen) {297} C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: From: Fred Foobar <foobar@example.com> C: Subject: afternoon meeting C: To: mooch@example.com C: Message-Id: <B27397-0100000@example.com> C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: S: A003 OK [APPENDUID 38505 3955] APPEND completed C: A004 COPY 2:4 meeting S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done C: A005 UID COPY 305:310 meeting S: A005 OK No matching messages, so nothing copied C: A006 COPY 2 funny S: A006 OK Done C: A007 SELECT funny S: * 1 EXISTS S: * 1 RECENT S: * OK [UNSEEN 1] Message 1 is first unseen S: * OK [UIDVALIDITY 3857529045] Validity session-only S: * OK [UIDNEXT 2] Predicted next UID S: * NO [UIDNOTSTICKY] Non-persistent UIDs S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited S: A007 OK [READ-WRITE] SELECT completed
例：C：A003 APPENDセーブメッセージ{297} C（\見て）：日付：月、1994年2月7日21時52分25秒-0800（PST）C：から：フレッドFOOBAR <foobar@example.com> C：件名：午後の会議C：TO：mooch@example.com C：メッセージ-ID：<B27397-0100000@example.com> C：MIME-バージョン：1.0 C：のContent-Type：text / plainの。 CHARSET = US-ASCII C：C：こんにちはジョー、あなたは私たちが明日3時30分に会うことができると思いますか？ C：S：A003 OK [APPENDUID 38505 3955] APPEND完了C：A004 COPY 2：4会議S：A004 OKなしOK A005：A005 UID COPY 305：310会議S [COPYUID 38505 304319：320 3956：3958]はCを完了C A006 OK完了：メッセージに一致するので、何もコピーされたC：A006コピー2面白いS A007面白いSを選択：* 1 RECENT S：* OK [UNSEEN 1]メッセージ1は、第1見えないSである：* OK [* 1がSをEXISTS UIDVALIDITY 3857529045]有効セッションのみのS：* OK [UIDNEXT 2]予測された次のUIDのS：* NO [UIDNOTSTICKY]非永続のUID S：* FLAGS（\回答\フラグ付き\削除された\見\案）S：* OK [ PERMANENTFLAGS（\削除された\見られる）]限定S：A007のOK [READ-WRITE]を選択完了
In this example, A003 and A004 demonstrate successful appending and copying to a mailbox that returns the UIDs assigned to the messages. A005 is an example in which no messages were copied; this is because in A003, we see that message 2 had UID 304, and message 3 had UID 319; therefore, UIDs 305 through 310 do not exist (refer to section 2.3.1.1 of [IMAP] for further explanation). A006 is an example of a message being copied that did not return a COPYUID; and, as expected, A007 shows that the mail store containing that mailbox does not support persistent UIDs.
この例では、A003とA004は、メッセージに割り当てられたUIDを返すメールボックスに成功添付してコピーを示しています。 A005には、メッセージがコピーされなかったした例です。 A003で、我々はそのメッセージ2は、UID 304持っていた、とメッセージ3は、UID 319だった見ためです。従って、310を介してのUID 305が存在しない（さらなる説明については、[IMAP]のセクション2.3.1.1を参照）。 A006はCOPYUIDを返さなかったコピーされるメッセージの一例です。そして、予想通り、A007は、そのメールボックスを含むメールストアは、永続的なUIDをサポートしていないことを示しています。
Formal syntax is defined using ABNF [ABNF], which extends the ABNF rules defined in [IMAP]. The IMAP4 ABNF should be imported before attempting to validate these rules.
正式な構文は[IMAP]で定義されたABNF規則を拡張ABNF [ABNF]を使用して定義されます。 IMAP4 ABNFは、これらのルールを検証しようとする前にインポートする必要があります。
append-uid = uniqueid
追加-UID =一意ID
capability =/ "UIDPLUS" command-select =/ uid-expunge
機能= / "UIDPLUS" コマンドを選択= / UID-EXPUNGE
resp-code-apnd = "APPENDUID" SP nz-number SP append-uid
応答コード-SUP =「APPENDUID「SPのSPはappend、NZ-数のuid
resp-code-copy = "COPYUID" SP nz-number SP uid-set SP uid-set
RESP-コードコピー= "COPYUID" SP NZ-数SPのUID-セットSPのUID-セット
resp-text-code =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY" ; incorporated before the expansion rule of ; atom [SP 1*<any TEXT-CHAR except "]">] ; that appears in [IMAP]
RESP-テキストコード= / RESP-コード-apnd / RESP-コードコピー/ "UIDNOTSTICKY"。の拡張ルールの前に組み込まれるが、原子[SP 1 * <以外の任意のTEXT-CHAR "]">]。それは、[IMAP]に表示されます。
uid-expunge = "UID" SP "EXPUNGE" SP sequence-set
UID-EXPUNGE = "UID" SP "EXPUNGE" SPシーケンスセット
uid-set = (uniqueid / uid-range) *("," uid-set)
UIDセット=（一意ID / UIDレンジ）*（ "" UIDセット）
uid-range = (uniqueid ":" uniqueid) ; two uniqueid values and all values ; between these two regards of order. ; Example: 2:4 and 4:2 are equivalent.
UID-範囲=（一意ID "：" 一意ID）。 2つの一意IDの値およびすべての値。オーダーのこれら二つの点の間。 ;例：2：4,4：2は等価です。
Servers that support [MULTIAPPEND] will have the following extension to the above rules:
[MULTIAPPEND]サポートするサーバーは、上記のルールに次の拡張子が付いています。
append-uid =/ uid-set ; only permitted if client uses [MULTIAPPEND] ; to append multiple messages.
追加-UID = / UIDセット。クライアントは[MULTIAPPEND]使用している場合にのみ許可。複数のメッセージを追加します。
The COPYUID and APPENDUID response codes return information about the mailbox, which may be considered sensitive if the mailbox has permissions set that permit the client to COPY or APPEND to the mailbox, but not SELECT or EXAMINE it.
COPYUIDとAPPENDUID応答コードは、メールボックスにコピーまたはメールボックスにAPPENDが、SELECTまたはそれを調べないようにクライアントを許可するアクセス権が設定されている場合は機密とみなすことができるメールボックスに関する情報を返します。
Consequently, these response codes SHOULD NOT be issued if the client does not have access to SELECT or EXAMINE the mailbox.
クライアントがメールボックスを選択するか検討するために、アクセス権を持っていない場合は結果的に、これらの応答コードが発行されるべきではありません。
This document constitutes registration of the UIDPLUS capability in the imap4-capabilities registry, replacing [RFC2359].
このドキュメントは[RFC2359]を置き換える、IMAP4、機能レジストリにUIDPLUS能力の登録を構成しています。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.
[MULTIAPPEND]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - MULTIAPPEND拡張"、RFC 3502、2003年3月。
[RFC2359] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1998.
[RFC2359]マイヤーズ、J.、 "IMAP4 UIDPLUS拡張"、RFC 2359、1998年6月。
This document obsoletes [RFC2359]. However, it is based upon that document, and takes substantial text from it (albeit with numerous clarifications in wording).
この文書では、[RFC2359]を廃止します。しかし、それは、その文書に基づいて、それから（言葉遣いで数々の明確化とはいえ）かなりのテキストをとります。
[RFC2359] implied that a server must always return COPYUID/APPENDUID data; thus suggesting that in such cases the server should return arbitrary data if the destination mailbox did not support persistent UIDs. This document adds the UIDNOTSTICKY response code to indicate that a mailbox does not support persistent UIDs, and stipulates that a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY (or APPEND) destination mailbox has UIDNOTSTICKY status.
[RFC2359]は、サーバが常にCOPYUID / APPENDUIDデータを返さなければならないことを暗示しました。したがって先のメールボックスが永続的なUIDをサポートしていませんでした場合は、このようなケースでは、サーバが任意のデータを返すべきであることを示唆しています。この文書では、メールボックスが永続的なUIDをサポートしていないことを示すためにUIDNOTSTICKY応答コードを追加し、COPY（またはAPPEND）送信先のメールボックスがUIDNOTSTICKYのステータスを持っている場合UIDPLUSサーバがCOPYUID / APPENDUIDデータを返さないと規定しています。
Author's Address
著者のアドレス
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
マーク・R.クリスピン・ネットワークとワシントン4545の分散コンピューティング大学第15回アベニューNEシアトル、WA 98105から4527
Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU
電話：（206）543-5762 Eメール：MRC@CAC.Washington.EDU
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。