計算機の世界 Top
新規
編集
2006年4月に公開された、RFC4469 [Internet Message Access Protocol (IMAP) CATENATE Extension] (IMAP CATENATE拡張) の日本語訳です。謝辞と文献の箇所は原文のままです。
CATENATEは、IMAP4サーバに置かれたメールを、「事前にダウンロードすることなく」編集するための拡張コマンドです。例えば、携帯電話のようなリソースが限られたデバイスから、下書きメールにデータを追記するような場合に便利です。
原文は、http://www.ietf.org/rfc/rfc4469.txt をご参照下さい。邦訳の誤りにお気づきの場合、ページ最下部のメールアドレスまでご連絡いただければ幸いです。
なお、可読性向上のため、ページのヘッダ・フッタを省略し、原文には無い改行を、適宜挿入しております。ご了承下さい。
Network Working Group P. Resnick Request for Comments: 4469 QUALCOMM Incorporated Updates: 3501, 3502 April 2006 Category: Standards Track
Internet Message Access Protocol (IMAP) CATENATE Extension
Internet Message Access Protocol (IMAP) CATENATE (連結) 拡張
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.
この文書は、インターネットコミュニティに向けて、インターネットの標準規格プロトコルを規定し、改良のための議論と提案を求めるものである。本プロトコルの標準化の進捗、および位置づけは、"Internet Official Protocol Standards" (STD 1)の最新版を参照されたい。このメモの配布に制限はない。
Copyright (C) The Internet Society (2006).
The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server.
Internet Message Access Protocol (IMAP) のCATENATE拡張は、APPENDコマンドを拡張し、IMAPサーバ上の既存メッセージの一部(または全部)と、新規データを組み合わせたメッセージを、クライアントがIMAPサーバ上に生成できるようにする。
クライアントは、この拡張を用い、あらかじめデータをダウンロード/アップロードすることなく、既存のメッセージの一部を、新規メッセージに付加できる。
The CATENATE extension to the Internet Message Access Protocol (IMAP) [1] allows the client to create a message on the server that can include the text of messages (or parts of messages) that already exist on the server without having to FETCH them and APPEND them back to the server. The CATENATE extension extends the APPEND command so that, instead of a single message literal, the command can take as arguments any combination of message literals (as described in IMAP [1]) and message URLs (as described in the IMAP URL Scheme [2] specification). The server takes all the pieces and catenates them into the output message. The CATENATE extension can also coexist with the MULTIAPPEND extension [3] to APPEND multiple messages in a single command.
Internet Message Access Protocol (IMAP) [1](RFC 3501)のCATENATE拡張により、クライアントは、IMAPサーバ上の既存メッセージのテキスト(またはメッセージの一部)を含むメッセージを、事前のFETCH・サーバへの再APPENDなしに、IMAPサーバ上に生成できる。
CATENATE拡張は、コマンドが、単一のメッセージリテラルの代わりに、複数のメッセージリテラル (IMAP[1](RFC 3501)に記述あり) とURL (IMAP URLスキーマ[2](RFC 2192)に記述あり) を含むことができるように、APPENDコマンドを拡張する。サーバは、それらの部品すべてを受け入れ、出力メッセージに連結する。
CATENATE拡張は、一回のコマンドで複数のメッセージをAPPENDするために、MULTIAPPEND拡張[3](RFC 3502)と共存することができる。
There are some obvious uses for the CATENATE extension. The motivating use case was to provide a way for a resource-constrained client to compose a message for subsequent submission that contains data that already exists in that client's IMAP store. Because the client does not have to download and re-upload potentially large message parts, bandwidth and processing limitations do not have as much impact. In addition, since the client can create a message in its own IMAP store, the command also addresses the desire of the client to archive a copy of a sent message without having to upload the message twice. (Mechanisms for sending the message are outside the scope of this document.)
CATENATE拡張には、明快な用途がいくつも存在する。
積極的に使いたくなる場面として、リソースの制限されたクライアントに、既にIMAPのストアにあるメッセージの続きを書く手段を提供すること、が挙げられる。クライアントは、巨大なこともあるメッセージパーツをダウンロード/再アップロードする必要がないので、バンド幅や処理能力の制約が、比較的、影響を与えずに済む。
更にこのコマンドは、送りたいと思っているメッセージを、クライアントがIMAPのストアに生成してからずっと、それがどれであるか明示して保管でき、クライアントは、何度もメッセージをアップロードする必要がない。(メッセージを送信するメカニズムは、この文書の範疇外である)
The extended APPEND command can also be used to copy parts of a message to another mailbox for archival purposes while getting rid of undesired parts. In environments where server storage is limited, a client could get rid of large message parts by copying over only the necessary parts and then deleting the original message. The mechanism could also be used to add data to a message (such as prepending message header fields) or to include other data by making a copy of the original and catenating the new data.
拡張されたAPPENDコマンドは、メッセージの一部を、保管用として別メールボックスにコピーすることもでき、これは一方で、不要な部分の除去に使える。
サーバのストレージ容量が限られた環境において、クライアントは、メッセージの必要な部分だけを複製し、オリジナルを削除することで、巨大なメッセージの不要部分を削除できる。
このメカニズムは、メッセージへのデータ追加(メッセージヘッダの追加)や、元データのコピーと、データ連結による、既存外部データの追加にも使用できる。
A server that supports this extension returns "CATENATE" as one of the responses to the CAPABILITY command.
この拡張をサポートするサーバは、CAPABILITYコマンドの応答のひとつに、"CATENATE"を返す。
mailbox name (The following can be repeated in the presence of the MULTIAPPEND extension [3])
(MULTIAPPEND拡張[3](RFC 3502)が存在する場合、以下は繰り返してもよい)
OPTIONAL flag parenthesized list OPTIONAL date/time string a single message literal or one or more message parts to catenate, specified as:
連結したい単一のメッセージリテラル、または一つ以上のメッセージパート。以下のように定義される:
message literal or message (or message part) URL
OPTIONAL NO responses: BADURL, TOOBIG
OK - append completed
OK - 追加完了
NO - append error: can't append to that mailbox, error
in flags or date/time or message text, or can't
fetch that data
NO - 追加エラー: 当該メールボックスへの追加に失敗。フラグ、日付/時刻、メッセージテキストに問題がある。または、データの取得に失敗。
BAD - command unknown or arguments invalid
BAD - 不明なコマンド。または、引数が不正。
The APPEND command concatenates all the message parts and appends them as a new message to the end of the specified mailbox. The parenthesized flag list and date/time string set the flags and the internal date, respectively, as described in IMAP [1]. The subsequent command parameters specify the message parts that are appended sequentially to the output message.
APPENDコマンドは、全メッセージパートを連結し、メールボックスの最後に、新規メッセージとして追加する。
カッコで囲まれたフラグのリストと、日付/時刻文字列によって、IMAP [1](RFC 3501)の記述のとおり、それぞれフラグと内部時刻をセットする。
その次のコマンドパラメータは、出力メッセージに連続的に追加されるメッセージパートを指定する。
If the original form of APPEND is used, a message literal follows the optional flag list and date/time string, which is appended as described in IMAP [1]. If the extended form is used, "CATENATE" and a parenthesized list of message literals and message URLs follows, each of which is appended to the new message. If a message literal is specified (indicated by "TEXT"), the octets following the count are appended. If a message URL is specified (indicated by "URL"), the octets of the body part pointed to by that URL are appended, as if the literal returned in a FETCH BODY response were put in place of the message part specifier. The APPEND command does not cause the \Seen flag to be set for any catenated body part. The APPEND command does not change the selected mailbox.
元来の形式のAPPENDが使用される場合、メッセージリテラルは、IMAP [1](RFC 3501)にあるとおり追加された、オプションのフラグリストと、日付/時刻文字列を伴う。
拡張形式が使用される場合、"CATENATE"、およびカッコで囲まれたメッセージリテラルとURLのリスト(訳注1)を伴い、これらは新規メッセージに追加される。メッセージリテラル("TEXT"で示される)が指定された場合、リテラルを数えたオクテット数が追加される(訳注2)。メッセージのURL("URL"で示される)が指定された場合、そのURLが指すボディ部のオクテット数が、さも、「FETCH BODYで返されたリテラルがメッセージ部指定子 (message part specifier) の位置にある」かのごとく、追加される。
APPENDコマンドは、連結されたボディ部にセットされる\Seenフラグの原因とはならない。APPENDコマンドは、選択されたメールボックスを変更しない。
"follows"なので、「カッコで囲まれた」は、"URLs"でなく、全体を修飾していると考えました。どうでしょう。
「オクテット数」は、{}で囲まれた数字列で、次にクライアントが送るコマンドの直前までのオクテット数を指します。オペレーションの区切りの改行 (CR + LF = 2オクテット) も含めて数えます。
判りにくかったら、[付録A. サンプル集]の、C: で始まる行を、上から順に追ってみて下さい。例えば、TEXT {40}と書かれていたら、「その次の"C: "で始まる行」の先頭から40オクテットが、メッセージリテラルです。多分。
In the extended APPEND command, the string following "URL" is an IMAP URL [2] and is interpreted according to the rules of [2]. The present document only describes the behavior of the command using IMAP URLs that refer to specific messages or message parts on the current IMAP server from the current authenticated IMAP session. Because of that, only relative IMAP message or message part URLs (i.e., those having no scheme or <iserver>) are used. The base URL for evaluating the relative URL is considered "imap://user@server/", where "user" is the user name of the currently authenticated user and "server" is the domain name of the current server. When in the selected state, the base URL is considered "imap://user@server/mailbox", where "mailbox" is the encoded name of the currently selected mailbox. Additionally, since the APPEND command is valid in the authenticated state of an IMAP session, no further LOGIN or AUTHENTICATE command is performed for URLs specified in the extended APPEND command.
拡張されたAPPENDコマンドでは、"URL"に続く文字列は、IMAP URL[2](RFC 2192)であり、[2]の規則に従って解釈される。この文書は、『「現在認証済みのIMAPセッションが」「現在使用中のIMAPサーバ上で参照している」「メッセージまたはメッセージの一部」を指すIMAP URL』を使用するコマンドの挙動についてのみ述べる。
そのため、使用できるのは「メッセージまたはメッセージ」の相対URL(スキーマの無いものや、<iserver>等)のみとする。相対URLを評価するためのベースURLは、"imap://user@server/"である。ここで"user"は、現在認証済みのユーザ名、"server"は、現在使用中のサーバのドメイン名とする。
ある条件下では、ベースURLは、"imap://user@server/mailbox"となる。"mailbox"は、エンコード済みの、現在選択されたメールボックスの名称とする。
加えて、一度APPENDコマンドがIMAPセッションで認証された状態となった以後は、更なるLOGINやAUTHENTICATEコマンドは、拡張APPENDコマンドのURL指定において、機能しない。
Note: Use of an absolute IMAP URL or any URL that refers to
anything other than a message or message part from the current
authenticated IMAP session is outside the scope of this document
and would require an extension to this specification, and a server
implementing only this specification would return NO to such a
request.
注意: 現在認証済みのIMAPセッションから範疇外のメッセージ、またはメッセージの一部を指す「絶対IMAP URL」または「あらゆるURL」の使用に関しては、本文書の対象外であり、本仕様の拡張が必要である。
また、本仕様のみを実装したサーバは、このようなURLリクエストに対し、NOを返すこととなる。
The client is responsible for making sure that the catenated message is in the format of an Internet Message Format (RFC 2822) [4] or Multipurpose Internet Mail Extension (MIME) [5] message. In particular, when a URL is catenated, the server copies octets, unchanged, from the indicated message or message part to the catenated message. It does no data conversion (e.g., MIME transfer encodings) nor any verification that the data is appropriate for the MIME part of the message into which it is inserted. The client is also responsible for inserting appropriate MIME boundaries between body parts, and writing MIME Content-Type and Content-Transfer- Encoding lines as needed in the appropriate places.
クライアントは、連結したメッセージが、Internet Message形式 (RFC 2822) [4](RFC 2822)またはMultipurpose Internet Mail Extension (MIME) [5](RFC 2045)メッセージになっていることを保証する責任がある。
特に、URLを連結する場合、サーバは、指定されたメッセージまたはメッセージの一部から、オクテットを変更することなく、連結メッセージにコピーする。データ変換 (MIME trasfer encodings など) や、データが、挿入先のメッセージのMIMEパートとして適切であるかの検証等は、一切行われない。
また、クライアントは、適切なMIME boundary (区切り) をボディパーツ間に挿入し、適切な場所に必要に応じ、MIME のContent-Type、Content-Transfer-Encoding行を記載する責任も負う。
Responses behave just as the original APPEND command described in IMAP [1]. If the server implements the IMAP UIDPLUS extension [6], it will also return an APPENDUID response code in the tagged OK response. Two response codes are provided in Section 4 that can be used in the tagged NO response if the APPEND command fails.
レスポンスは、IMAP[1](RFC 3501)で述べられている「元来の形式のAPPENDコマンド」と同様に動作する。
サーバが、IMAP UIDPLUS拡張[6](RFC 4315)を実装している場合、タグ付けされたOK中に、APPENDUIDレスポンスコードも返される。
4.節で述べる2つのレスポンスコードを、APPENDコマンドが失敗した際にタグ付けされたNO中で使用できる。
When a APPEND command fails, it may return a response code that describes a reason for the failure.
APPENDコマンドが失敗した場合、失敗の理由を述べるレスポンスコードを返してもよい。
BADURL レスポンス (BADURL Response)The BADURL response code is returned if the APPEND fails to process one of the specified URLs. Possible reasons for this are bad URL syntax, unrecognized URL schema, invalid message UID, or invalid body part. The BADURL response code contains the first URL specified as a parameter to the APPEND command that has caused the operation to fail.
BADURLレスポンスコードは、指定されたURLの中に、APPENDが処理に失敗したものが含まれていた場合に返される。あり得る理由としては、URLの文法不正、未知のURLスキーマ、無効なメッセージUID、無効なボディ部、が挙げられる。
BADURLレスポンスコードには、APPENDコマンドにパラメータとして与えられたURLのうち、処理に失敗する原因となった、一番最初のものが含まれている。
TOOBIG レスポンス (TOOBIG Response)The TOOBIG response code is returned if the resulting message will exceed the 4-GB IMAP message limit. This might happen, for example, if the client specifies 3 URLs for 2-GB messages. Note that even if the server doesn't return TOOBIG, it still has to be defensive against misbehaving or malicious clients that try to construct a message over the 4-GB limit. The server may also wish to return the TOOBIG response code if the resulting message exceeds a server- specific message size limit.
TOOBIGレスポンスコードは、生成されるメッセージが、IMAPメッセージの制限である4GBを超えた場合に返される。例えばこれは、クライアントが、2GBのメッセージを指すURLを3つ指定した場合などに起こる。
サーバは、たとえTOOBIGを返さなくとも、4GB以上のメッセージを作ろうとする無作法または悪意あるクライアントから、自身を防御する必要があることに、留意しなければならない。
サーバは、メッセージサイズの上限を自分で決めて、それを越すメッセージの生成に対し、TOOBIGレスポンスコードを返してもよい。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) [7] notation. Elements not defined here can be found in the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions [8] specifications. Note that capability and resp-text-code are extended from the IMAP [1] specification and append-data is extended from the IMAP ABNF extensions [8] specification.
以下の文法詳細は、Augmented Backus-Naur Form (ABNF) [7](RFC 4234)表示を使用する。
ここに定義のない要素は、ABNF [7]、IMAP [1](RFC 3501)、およびIMAP ABNF 拡張 [8](RFC 4466)を参照のこと。
append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"
cat-part = text-literal / url
text-literal = "TEXT" SP literal
url = "URL" SP astring
resp-text-code =/ toobig-response-code / badurl-response-code
toobig-response-code = "TOOBIG"
badurl-response-code = "BADURL" SP url-resp-text
url-resp-text = 1*(%x01-09 /
%x0B-0C /
%x0E-5B /
%x5D-FE) ; Any TEXT-CHAR except "]"
"]"を除くすべてのTEXT-CHAR
capability =/ "CATENATE"
The astring in the definition of url and the url-resp-text in the definition of badurl-response-code each contain an imapurl as defined by [2].
「url定義内のastring」および「badurl-response-code定義内のurl-resp-text」は、[2](RFC 2192)で定義されるimapurlを含む。
Thanks to the members of the LEMONADE working group for their input. Special thanks to Alexey Melnikov for the examples.
The CATENATE extension does not raise any security considerations that are not present for the base protocol or in the use of IMAP URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2] documents.
「基礎となるプロトコル」、および「IMAP URLの使用」に存在しないセキュリティ上の考慮事項は、CATENATE拡張によっても、顕著化することはない。
これら2つの考慮事項は、IMAP[1](RFC 3501)と、IMAP URL[2](RFC 2192)にて議論されている。
IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at <http://www.iana.org/assignments/imap4-capabilities>. This document defines the CATENATE IMAP capability. The IANA has added this capability to the registry.
IMAP4の機能は、スタンダードトラックの発行、またはIESGが承認した実験的RFCによって登録される。現在のレジストリは、<http://www.iana.org/assignments/imap4-capabilities>である。本文書は、CATENATE IMAP機能を定義している。IANAは、この機能をレジストリに追加した。
Lines not starting with "C: " or "S: " are continuations of the previous lines.
先頭が「"C: "または"S: "」でない行は、前の行からの継続である。
The original message in examples 1 and 2 below (UID = 20) has the following structure:
下記、例1、2 (UID = 20) の元のメッセージは、以下の構造を持つ。
multipart/mixed MIME message with two body parts:
以下2つのボディ部を持つ、MIMEタイプmultipart/mixedのメッセージ:
1. text/plain 2. application/x-zip-compressed
Example 1: The following example demonstrates how a CATENATE client can replace an attachment in a draft message, without the need to download it to the client and upload it back.
例1: 以下、CATENATEクライアントが、どのように下書きメッセージ内の添付ファイルを、一旦ダウンロード/再アップロードすることなく置換するか紹介する。
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
(URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=HEADER"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1" TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050907--
C: )
S: A003 OK catenate append completed
Example 2: The following example demonstrates how the CATENATE extension can be used to replace edited text in a draft message, as well as header fields for the top level message part (e.g., Subject has changed). The previous version of the draft is marked as \Deleted. Note that the server also supports the UIDPLUS extension, so the APPENDUID response code is returned in the successful OK response to the APPEND command.
例2: 以下、CATENATE拡張が、どのように下書きメッセージ内の編集中テキストや、最上位のメッセージパートのヘッダ領域(例えば、Subjectを変更している)を置換するか、紹介する。
下書きの、直前の版 (バージョン) は、\Deletedとマークされる。サーバはUIDPLUS拡張もサポートするので、「APPENDコマンドのOKレスポンスが入るべき場所に、APPENDUIDレスポンスコードが入る」という点に留意しなければならない。
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738}
S: + Ready for literal data
C: Return-Path: <bar@example.org>
C: Received: from [127.0.0.2]
C: by rufus.example.org via TCP (internal) with ESMTPA;
C: Thu, 11 Nov 2004 16:57:07 +0000
C: Message-ID: <419399E1.6000505@example.org>
C: Date: Thu, 12 Nov 2004 16:57:05 +0000
C: From: Bob Ar <bar@example.org>
C: X-Accept-Language: en-us, en
C: MIME-Version: 1.0
C: To: foo@example.net
C: Subject: About our holiday trip
C: Content-Type: multipart/mixed;
C: boundary="------------030308070208000400050907"
C:
C: --------------030308070208000400050907
C: Content-Type: text/plain; charset=us-ascii; format=flowed
C: Content-Transfer-Encoding: 7bit
C:
C: Our travel agent has sent the updated schedule.
C:
C: Cheers,
C: Bob
C: --------------030308070208000400050907
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050907--
C: )
S: A003 OK [APPENDUID 385759045 45] append Completed
C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted)
S: A004 OK STORE completed
Example 3: The following example demonstrates how the CATENATE extension can be used to strip attachments. Below, a PowerPoint attachment was replaced by a small text part explaining that the attachment was stripped.
例3: 以下、CATENATE拡張が、どのように添付ファイルを削除するか紹介する。PowerPointファイルが、「削除されました」という旨の短いテキストに置換されている。
C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
(URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=HEADER"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050903
C: URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1.MIME"
URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1" TEXT {255}
S: + Ready for literal data
C:
C: --------------030308070208000400050903
C: Content-type: text/plain; charset="us-ascii"
C: Content-transfer-encoding: 7bit
C:
C: This body part contained a Power Point presentation that was
C: deleted upon your request.
C: --------------030308070208000400050903--
C: )
S: A003 OK append Completed
Example 4: The following example demonstrates a failed APPEND command. The server returns the BADURL response code to indicate that one of the provided URLs is invalid. This example also demonstrates how the CATENATE extension can be used to construct a digest of several messages.
例4: 以下は、APPENDコマンドが失敗する様子の紹介である。サーバが、「与えられたURLの一つが無効である」として、BADURLレスポンスコードを返している。またこの例は、CATENATE拡張が、複数のメッセージのダイジェスト(要約)を組み立てる様子も紹介している。
C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541}
S: + Ready for literal data
C: Return-Path: <foo@example.org>
C: Received: from [127.0.0.2]
C: by rufus.example.org via TCP (internal) with ESMTPA;
C: Thu, 11 Nov 2004 16:57:07 +0000
C: Message-ID: <419399E1.6000505@example.org>
C: Date: Thu, 21 Nov 2004 16:57:05 +0000
C: From: Farren Oo <foo@example.org>
C: X-Accept-Language: en-us, en
C: MIME-Version: 1.0
C: To: bar@example.org
C: Subject: Digest of the mailing list for today
C: Content-Type: multipart/digest;
C: boundary="------------030308070208000400050904"
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=113330/;section=1.5.9"
TEXT {42}
S: + Ready for literal data
C:
C: --------------030308070208000400050904
C: URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {44}
S: + Ready for literal data
C:
C: --------------030308070208000400050904--
C: )
S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330;
section=1.5.9"] CATENATE append has failed, one message expunged
Note that the server could have validated the URLs as they were received and therefore could have returned the tagged NO response with BADURL response-code in place of any continuation request after the URL was received.
サーバは、URLを受け取りつつ検証することもできる。故に、「URLを受け取った次に来るリクエスト」があるべき場所に、「response-code BADURLの付いた、NOレスポンス」が入る可能性もある点に、注意が必要である。
[1] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
RFC 3501, March 2003.
[2] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[3] Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, March 2003.
[4] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[6] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS
extension", RFC 4315, December 2005.
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[8] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF",
RFC 4466, April 2006.
Peter W. Resnick QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US
Phone: +1 858 651 4478 EMail: presnick@qualcomm.com URI: http://www.qualcomm.com/~presnick/
Copyright (C) The Internet Society (2006).
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.
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.
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.
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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC編集業務に対する資金は、IETF Administrative Support Activity (IASA) により提供されている。
