RFC 4315 - Internet Message Access Protocol (IMAP)

RFC 4315 - Internet Message Access Protocol (IMAP) - UIDPLUS extension 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4315
タイトル : RFC 4315 - インターネットメッセージアクセスプロトコル（IMAP） - uidplus拡張機能
翻訳編集 : 自動生成

[要約] RFC 4315はIMAPのUIDPLUS拡張機能に関するものであり、メッセージの一意識別子（UID）の操作を拡張する。目的は、メッセージの一意性を保ちながら、効率的なメッセージの操作と同期を可能にすること。

Network Working Group                                         M. Crispin
Request for Comments: 4315                                 December 2005
Obsoletes: 2359
Category: Standards Track

Internet Message Access Protocol (IMAP) - UIDPLUS extension

インターネットメッセージアクセスプロトコル（IMAP） - uidplus拡張機能

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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の機能は、主に切断された使用クライアントを対象としています。

1. Introduction and Overview

1. はじめにと概要

The UIDPLUS extension is present in any IMAP server implementation that returns "UIDPLUS" as one of the supported capabilities to the CAPABILITY command.

uidplus拡張子は、「uidplus」をサポートされている機能コマンドの1つとして返す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の機能の追加機能は最適化されています。クライアントは、基本プロトコルの機能を使用することにより、効率が低いにもかかわらず、同等の機能を提供できます。

1.1. Conventions Used in This Document

1.1. このドキュメントで使用されている規則

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].

「必須」、「そうしない」、「必須」、「「shall」、「shall」、「suff」、「 "wuth" not "、" may "、" optional]は、このドキュメントの「オプション」は、[キーワード]で説明されています。

A "UID set" is similar to the [IMAP] sequence set; however, the "*" value for a sequence number is not permitted.

「UIDセット」は[IMAP]シーケンスセットに似ています。ただし、シーケンス番号の「*」値は許可されていません。

2. Additional Commands

2. 追加のコマンド

The following command definition is an extension to [IMAP] section 6.4.

次のコマンド定義は、[IMAP]セクション6.4の拡張機能です。

2.1. UID EXPUNGE Command

2.1. uid expungeコマンド

Arguments: sequence set

引数：シーケンスセット

Data: untagged responses: EXPUNGE

データ：未編成の回答：obunge

Result: OK - expunge completed NO - expunge failure (e.g., permission denied) BAD - command unknown or arguments invalid

結果：OK -OFBUNGE COMPLEICTNO NO -OFBUNGE失敗（たとえば、許可を拒否された）悪い - コマンド不明または引数が無効です

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コマンドは、両方とも\削除されたフラグセットを持つすべてのメッセージを永続的に削除し、現在選択されているメールボックスから指定されたシーケンスセットに含まれるUIDを持っています。メッセージに\削除されたフラグセットがないか、指定されたシーケンスセットに含まれていない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.

このコマンドは、クライアントを切断した場合に特に役立ちます。サーバーと再同期するときに抹消する代わりにuid obungeを使用することにより、クライアントは、クライアントが最後に接続された時間とクライアントが再同期するまでに他のクライアントによって削除されたものとしてマークされたメッセージを不注意に削除しないようにすることができます。

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コマンドを発行する必要があります。最後に、クライアントはストアコマンドを使用して、一時的に削除されたメッセージの\削除フラグを復元する必要があります。

Alternatively, the client may fall back to using just the EXPUNGE command, risking the unintended removal of some messages.

あるいは、クライアントは、消去コマンドのみを使用して後退し、いくつかのメッセージの意図しない削除を危険にさらす場合があります。

   Example:    C: A003 UID EXPUNGE 3000:3002
               S: * 3 EXPUNGE
               S: * 3 EXPUNGE
               S: * 3 EXPUNGE
               S: A003 OK UID EXPUNGE completed

3. Additional Response Codes

3. 追加の応答コード

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.

クライアントがメールボックスにコピーまたは追加できるように設定されているメールボックスの場合、それを選択または調べることはできません。サーバーは、メールボックスに関する情報を開示して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応答コードを返さない場合、クライアントは宛先メールボックスを選択してこの情報を発見できます。宛先メールボックスにコピーまたは追加で配置されたメッセージの場所は、フェッチおよび/または検索コマンドを使用して決定できます（たとえば、メッセージIDまたは追加のメッセージに配置された一意のマーカーなど）。

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.

宛先メールボックスのuidialidityと、宛先メールボックスに追加されたメッセージに割り当てられたUIDが、メッセージがその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]拡張子もサポートし、複数のメッセージが追加コマンドに追加された場合、2番目の値は、追加のメッセージに割り当てられた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などの範囲を送信してはなりません。これは、[MultiaPendEnd]をサポートしていないクライアントが、UIDセットではなく1つの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).

宛先メールボックスのuidialidityが続いて、宛先メールボックスにコピーされ、宛先メールボックスのコピーされたメッセージに割り当てられた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またはシンボル「*」が含まれていない場合があります。

This response code is returned in a tagged OK response to the COPY command.

この応答コードは、コピーコマンドに対するタグ付き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をサポートしていないメールストアによってサポートされています。つまり、メールボックスが選択されるたびにuidiality性は異なります。したがって、このメールボックスに追加またはコピーしても、虫垂またはCopyUID応答コードは返されません。

This response code is returned in an untagged NO response to the SELECT command.

この応答コードは、SELECTコマンドへの未編成なしの応答で返されます。

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

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を返すメールボックスへのAppendingとコピーの成功とコピーを示しています。A005は、メッセージがコピーされなかった例です。これは、A003では、メッセージ2がUID 304を持ち、メッセージ3がUID 319を持っていたことがわかります。したがって、UIDS 305〜310は存在しません（詳細については、[IMAP]のセクション2.3.1.1を参照してください）。a006は、コピーを返さなかったメッセージがコピーされている例です。そして、予想どおり、A007は、メールボックスが永続的なUIDをサポートしていないことを含むメールストアを示しています。

4. Formal Syntax

4. 正式な構文

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

   capability      =/ "UIDPLUS"
      command-select  =/ uid-expunge

resp-code-apnd = "APPENDUID" SP nz-number SP append-uid

resp-code-apnd = "appenduid" sp nz-number sp append-uid

resp-code-copy = "COPYUID" SP nz-number SP uid-set SP uid-set

Resp-Code-Copy = "CopyUid" SP nz-Numbersp uid-set sp uid-set

   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]

uid-expunge = "UID" SP "EXPUNGE" SP sequence-set

uid-expunge = "uid" sp "obunge" sp sequence-set

   uid-set         = (uniqueid / uid-range) *("," uid-set)

   uid-range       = (uniqueid ":" uniqueid)
                     ; two uniqueid values and all values
                     ; between these two regards of order.
                     ; Example: 2:4 and 4:2 are equivalent.

Servers that support [MULTIAPPEND] will have the following extension to the above rules:

[MultiaPend]をサポートするサーバーには、上記のルールに次の拡張機能があります。

   append-uid      =/ uid-set
                     ; only permitted if client uses [MULTIAPPEND]
                     ; to append multiple messages.

5. Security Considerations

5. セキュリティに関する考慮事項

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応答コードは、メールボックスに関する情報を返します。これは、メールボックスにクライアントがメールボックスにコピーまたは追加できるようにする権限セットが設定されている場合、それを選択または調べることはできない場合に感度が高いと見なされる場合があります。

Consequently, these response codes SHOULD NOT be issued if the client does not have access to SELECT or EXAMINE the mailbox.

したがって、クライアントがメールボックスを選択または調べるためにアクセスできない場合、これらの応答コードを発行しないでください。

6. IANA Considerations

6. IANAの考慮事項

This document constitutes registration of the UIDPLUS capability in the imap4-capabilities registry, replacing [RFC2359].

このドキュメントは、[RFC2359]を置き換えて、IMAP4-CapabilitiesレジストリにおけるUIDPLUS機能の登録を構成します。

7. Normative References

7. 引用文献

[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。

[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[IMAP] Crispin、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.

[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.

[MultiaPend] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP） - マルチアドペンド拡張機能」、RFC 3502、2003年3月。

8. Informative References

8. 参考引用

[RFC2359] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1998.

[RFC2359] Myers、J。、「IMAP4 UIDPLUS EXTENTRY」、RFC 2359、1998年6月。

9. Changes from RFC 2359

9. RFC 2359からの変更

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をサポートしていない場合、サーバーは任意のデータを返す必要があることを示唆しています。このドキュメントでは、uidnotsticky応答コードを追加して、メールボックスが永続的なuidsをサポートしていないことを示し、uidplusサーバーがコピー（またはappend）宛先メールボックスにuidnotstickyステータスがあるときに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 15th Avenue NEシアトル、ワシントン州98105-4527

Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU

電話：（206）543-5762メール：mrc@cac.washington.edu

Full Copyright Statement

完全な著作権声明

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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。