RFC4315 日本語訳

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

コメントを求めるワーキンググループM.クリスピン要求をネットワークでつないでください: 4315 2005年12月は以下を時代遅れにします。 2359年のカテゴリ: 標準化過程

      Internet Message Access Protocol (IMAP) - UIDPLUS extension

インターネットMessage Accessプロトコル(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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(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.

インターネットMessage Accessプロトコル(IMAP)のUIDPLUS拡張子はいくつかのクライアント操作で時間と運用資金を短縮することを意図する1セットの特徴を提供します。 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拡張子はサポートしている能力の1つとして「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拡張子は追加コマンドを定義します。 さらに、このドキュメントはすべてのサーバ実装で返して、応答がSHOULDがあるIMAPでコード化する新しい状態を推薦します、UIDPLUS拡張子が実装されるかどうかにかかわらず。

   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:」 クライアントとサーバによってそれぞれ送られた系列を示してください。

Crispin                     Standards Track                     [Page 1]

RFC 4315                IMAP - UIDPLUS Extension           December 2005

クリスピン標準化過程[1ページ]RFC4315IMAP--UIDPLUS拡大2005年12月

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」、「5月」、このドキュメントで「任意」は中[キーワード]で説明されるように解釈されることであるべきです。

   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梢消コマンド

   Arguments:  sequence set

議論: シーケンスセット

   Data:       untagged responses: EXPUNGE

データ: 非タグ付けをされた応答: 梢消します。

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

結果: OK--完成したノーを梢消してください--失敗(例えば否定された許可)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を使用することによって、クライアントは、inadvertantlyに\Deletedとしてクライアントが最後に接された時、クライアントが再連動する時の間の他のクライアントによってマークされたどんなメッセージも取り除かないのを保証できます。

      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が能力であるとサポートしないなら、クライアントは一時Deletedがそれが取り除きたがっていないメッセージから旗を揚げさせる\を取り除くストアコマンドを使用することへ後ろへ下がるべきです、次に、EXPUNGEコマンドを発行して。 最終的に、クライアントはDeletedがそれが一時取り除かれたメッセージで旗を揚げさせる\を回復するストアコマンドを使用するべきです。

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

あるいはまた、クライアントはいくつかのメッセージの故意でない取り外しを危険にさらして、まさしくEXPUNGEコマンドを使用することへ後ろへ下がるかもしれません。

Crispin                     Standards Track                     [Page 2]

RFC 4315                IMAP - UIDPLUS Extension           December 2005

クリスピン標準化過程[2ページ]RFC4315IMAP--UIDPLUS拡大2005年12月

   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は: 3002秒間、3000を梢消します: * 3 Sを梢消してください: * 3 Sを梢消してください: * 3 Sを梢消してください: 完成したA003 OK UID EXPUNGE

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拡張子SHOULDの広告を出すサーバ実装がこれらの応答コードを返します。

   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かEXAMINEではなく、それ、SHOULD NOTがAPPENDUIDを送るサーバまたはCOPYUID応答がメールボックスの周りに情報を開示するようにコード化するメールボックスへのCOPYかAPPENDをさせることができるように許容を設定します。

   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、そして/または、検索命令(例えばMessage-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.

あて先メールボックスのUIDVALIDITYとあて先メールボックスの中の追加されたメッセージに割り当てられた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]拡大をサポートして、APPENDコマンドで複数のメッセージを追加したなら2番目の値が追加されたメッセージに割り当てられたUIDsを含むのを用意ができているUIDであるなら、オーダーでは、それらはAPPENDコマンドで伝えられました。 このUIDセットは「*」という異質なUIDsかシンボルを含まないかもしれません。

         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だけがセットしたと予想するからです。

Crispin                     Standards Track                     [Page 3]

RFC 4315                IMAP - UIDPLUS Extension           December 2005

クリスピン標準化過程[3ページ]RFC4315IMAP--UIDPLUS拡大2005年12月

      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.

UIDsはメールボックスの中に厳密に昇順で割り当てられます。([IMAP]を参照してください、.1の.1と)UID範囲が[IMAP]にあるセクション2.3。 特に、さまざまな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(あて先メールボックスにコピーされたソースメールボックスにメッセージのUIDsを含んでいて、あて先メールボックスにコピーされたメッセージに割り当てられたUIDsを含む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セットのどちらも「*」という異質なUIDsかシンボルを含まないかもしれません。

      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.

UIDsはメールボックスの中に厳密に昇順で割り当てられます。([IMAP]を参照してください、.1の.1と)UID範囲が[IMAP]にあるセクション2.3。 特に、さまざまな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.

選択されたメールボックスは永続的なUIDsをサポートしないメール店によって支えられます。 すなわち、UIDVALIDITYはメールボックスが選択される各回異なるでしょう。 その結果、このメールボックスへのAPPENDかCOPYが応答コードをAPPENDUIDか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.

以下に注意してください。 サーバSHOULD NOTには、どんなUIDNOTSTICKYメール店もあります。 この施設は、レガシーメールが永続的なUIDsをサポートするのが技術的に実行不可能である店であるとサポートするために存在しています。 新しいメール店を設計するとき、これは避けられるべきです。

Crispin                     Standards Track                     [Page 4]

RFC 4315                IMAP - UIDPLUS Extension           December 2005

クリスピン標準化過程[4ページ]RFC4315IMAP--UIDPLUS拡大2005年12月

   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の保存しているメッセージ(\Seen)297C: 日付: 月曜日、1994年2月7日21:52:25 -0800(太平洋標準時の)のC: From: フレッド Foobar <foobar@example.com 、gt;、C: Subject: 午後のミーティングC: To: mooch@example.com C: メッセージイド: <B27397-0100000@example.com>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: こんにちは、ジョー、あなたは私たちが明日の3:30に会うことができると思いますか? C: S: A003 OK[APPENDUID38505 3955]APPENDはCを完成しました: A004 COPY2:4ミーティングS: A004が承認する、[COPYUID38505 304,319: 320 3956: 3958] Cをします: A005 UID COPY305: 310 ミーティングS: メッセージに合っていないA005 OKによって、何もCをコピーしませんでした: A006 COPY2のおかしいS: Cが行われたA006OK: A007 SELECTのおかしいS: * 1が存在している、S: * 1、最近のS: * OK[UNSEEN1]メッセージ1は最初に、見えないSです: * OK[UIDVALIDITY3857529045]正当性セッションだけS: * OK[UIDNEXT2]は次のUID Sを予測しました: * [UIDNOTSTICKY]非永続的なUIDs Sがありません: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * OK[PERMANENTFLAGS(\は見られた\を削除した)]はSを制限しました: 完成したA007 OK[READ-WRITE]SELECT

   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はメッセージに割り当てられたUIDsを返すメールボックスへのうまくいっている追加とコピーを示します。 A005はメッセージが全くコピーされなかった例です。 これは私たちがA003でメッセージ2にはUID304があって、メッセージ3にはUID319があったのがわかるからです。 したがって、UIDs305〜310が存在していない、(セクション2.3.1を参照してください、詳細な説明のための.1[IMAP]) A006はCOPYUIDを返さなかったコピーされるメッセージに関する例です。 そして、予想されるように、A007は、そのメールボックスを含むメール店が永続的なUIDsをサポートしないのを示します。

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.

正式な構文は、ABNF[ABNF]([IMAP]で定義されたABNF規則を広げている)を使用することで定義されます。 IMAP4 ABNFはこれらの規則を有効にするのを試みる前に、インポートされるべきです。

   append-uid      = uniqueid

uidを追加している=uniqueid

   capability      =/ "UIDPLUS"

能力=/「UIDPLUS」

Crispin                     Standards Track                     [Page 5]

RFC 4315                IMAP - UIDPLUS Extension           December 2005

クリスピン標準化過程[5ページ]RFC4315IMAP--UIDPLUS拡大2005年12月

   command-select  =/ uid-expunge

/がuid梢消するコマンド選んだ=

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

respコードapndは"APPENDUID"SP nz-数のSPと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"。 拡張規則の前に盛込む、。 「原子、[どんなTEXT-CHARも除くSP1*<、」、]、「>]」 ; それは中に現れます。[IMAP]

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

「梢消="UID"SP」SPシーケンスセットをuid梢消してください。

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

uid-セット=(uniqueid / 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-範囲=(」 : 」 uniqueidをuniqueidします)。 2つのuniqueid値とすべての値。 オーダーのこれらの2つのあいさつの間で。 ; 例: 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]を使用する場合にだけ、受入れられます。 複数のメッセージを追加するために。

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応答コードはメールボックスに関して、それがSELECTかEXAMINEではなく、メールボックスへのCOPYかAPPENDにクライアントを可能にするという情報を返します。許容がメールボックスで設定するようになるなら、メールボックスは敏感であると考えられるかもしれません。それ。

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

その結果、これらの応答はSHOULD NOTをコード化します。クライアントがSELECTに近づく手段を持っていないか、またはメールボックスがEXAMINEが発行されるなら、発行されてください。

6.  IANA Considerations

6. IANA問題

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

[RFC2359]を取り替えて、このドキュメントはimap4-能力登録でのUIDPLUS能力の登録を構成します。

7.  Normative References

7. 引用規格

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

[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

Crispin                     Standards Track                     [Page 6]

RFC 4315                IMAP - UIDPLUS Extension           December 2005

クリスピン標準化過程[6ページ]RFC4315IMAP--UIDPLUS拡大2005年12月

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

[IMAP] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」

   [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月。

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

[MULTIAPPEND]クリスピン、M.、「インターネットはアクセス・プロトコル(IMAP)を通信させます--MULTIAPPEND拡張子」、RFC3502、3月2003日

8.  Informative References

8. 有益な参照

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

[RFC2359] マイアーズ、J.、「IMAP4 UIDPLUS拡張子」、RFC2359、1998年6月。

9.  Changes from RFC 2359

9. RFC2359からの変化

   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に返さなければならないのを含意しました。 その結果、あて先メールボックスが永続的なUIDsをサポートしないならそのような場合サーバが任意のデータを返すと示唆します。 このドキュメントは、メールボックスが永続的なUIDsをサポートしないのを示すために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.クリスピンネットワークと第15分散コンピューティングワシントン大学4545アベニューNeシアトル、ワシントン98105-4527

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

以下に電話をしてください。 (206) 543-5762 メールしてください: MRC@CAC.Washington.EDU

Crispin                     Standards Track                     [Page 7]

RFC 4315                IMAP - UIDPLUS Extension           December 2005

クリスピン標準化過程[7ページ]RFC4315IMAP--UIDPLUS拡大2005年12月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Crispin                     Standards Track                     [Page 8]

クリスピン標準化過程[8ページ]