RFC3348 日本語訳

Network Working Group                                          M. Gahrns
Request for Comments: 3348                                      R. Cheng
Category: Informational                                        Microsoft
                                                               July 2002

Gahrnsがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3348年のR.チェンカテゴリ: 情報のマイクロソフト2002年7月

             The Internet Message Action Protocol (IMAP4)
                        Child Mailbox Extension

インターネットメッセージ動作プロトコル(IMAP4)子供メールボックス拡大

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   The Internet Message Action Protocol (IMAP4) CHILDREN extension
   provides a mechanism for a client to efficiently determine if a
   particular mailbox has children, without issuing a LIST "" * or a
   LIST "" % for each mailbox.

クライアントが、特定のメールボックスで子供がいるかどうかと効率的に決心するように、インターネットMessage Actionプロトコル(IMAP4)CHILDREN拡張子はメカニズムを提供します、LISTを発行しないで「「*かリスト、「「各メールボックスのための%。」

1. Conventions used in this document

1. 本書では使用されるコンベンション

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.  If such lines are wrapped without a new "C:" or
   "S:" label, then the wrapping is for editorial clarity and is not
   part of the command.

例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。 そのような系列が新しいaなしで包装される、「C:」 または、「S:」 次に、ラベル、ラッピングは、編集の明快ためにあって、コマンドの一部ではありません。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?

2. Introduction and Overview

2. 序論と概要

   Many IMAP4 [RFC-2060] clients present to the user a hierarchical view
   of the mailboxes that a user has access to.  Rather than initially
   presenting to the user the entire mailbox hierarchy, it is often
   preferable to show to the user a collapsed outline list of the
   mailbox hierarchy (particularly if there is a large number of
   mailboxes).  The user can then expand the collapsed outline hierarchy
   as needed.  It is common to include within the collapsed hierarchy a

多くのIMAP4[RFC-2060]クライアントがユーザが近づく手段を持っているメールボックスの階層的な視点をユーザに提示します。 初めは全体のメールボックス階層構造をユーザに提示するよりむしろ、メールボックス階層構造の潰れているアウトラインリストをユーザに見せているのはしばしば望ましいです(特に多くのメールボックスがあれば)。 そして、ユーザは必要に応じて潰れているアウトライン階層構造を広げることができます。 潰れている階層構造の中にaを含んでいるのは一般的です。

Gahrns, et al.               Informational                      [Page 1]

RFC 3348             IMAP4 Child Mailbox Extension             July 2002

Gahrns、他 [1ページ]情報のRFC3348IMAP4子供メールボックス拡大2002年7月

   visual clue (such as a "+") to indicate that there are child
   mailboxes under a particular mailbox.  When the visual clue is
   clicked the hierarchy list is expanded to show the child mailboxes.

特定のメールボックスの下に子供メールボックスがあるのを示す視覚手がかり(「+」などの)。 視覚手がかりがクリックされるとき、階層構造リストは、子供メールボックスを見せているために広げられます。

   Several IMAP vendors implemented this proposal, and it is proposed to
   document this behavior and functionality as an Informational RFC.

いくつかのIMAPベンダーがこの提案を実装しました、そして、それは、Informational RFCとしてこの振舞いと機能性を記録するために提案されます。

   There is interest in addressing the general extensibility of the IMAP
   LIST command through an IMAP LIST Extension draft.  Similar
   functionality to the \HasChildren and \HasNoChildren flags could be
   incorporated into this new LIST Extension.  It is proposed that the
   more general LIST Extension draft proceed on the standards track with
   this proposal being relegated to informational status only.

IMAP LIST Extension草稿でIMAP LISTコマンドの一般的な伸展性を扱うことへの関心があります。 HasChildrenと\HasNoChildrenが旗を揚げさせる\への同様の機能性をこの新しいLIST Extensionに組み入れることができました。 この提案が情報の状態だけに左遷されている状態で、より一般的なLIST Extension草稿が標準化過程の上で続くよう提案されます。

   If the functionality of the \HasChildren and \HasNoChildren flags
   were incorporated into a more general LIST extension, this would have
   the advantage that a client could then have the opportunity to
   request whether or not the server should return this information.
   This would be an advantage over the current draft for servers where
   this information is expensive to compute, since the server would only
   need to compute the information when it knew that the client
   requesting the information was able to consume it.

HasChildrenと\HasNoChildrenが旗を揚げさせる\の機能性が、より一般的なLIST拡張子に組み入れられるなら、これで、サーバがこの情報を返すべきであるか否かに関係なく、クライアントがそしてときにそうすることができた利点は要求する機会を持っているでしょうに。 これはこの情報が計算するために高価であるサーバのための現在の草稿より利点でしょう、サーバが、それが、いつ情報を要求するクライアントがそれを消費できるのを知っていたかという情報を計算する必要があるだけでしょう、したがって。

3. Requirements

3. 要件

   IMAP4 servers that support this extension MUST list the keyword
   CHILDREN in their CAPABILITY response.

この拡大をサポートするIMAP4サーバは彼らのCAPABILITY応答でキーワードCHILDRENを記載しなければなりません。

   The CHILDREN extension defines two new attributes that MAY be
   returned within a LIST response.

CHILDREN拡張子はLIST応答の中で返されるかもしれない2つの新しい属性を定義します。

   \HasChildren - The presence of this attribute indicates that the
   mailbox has child mailboxes.

\HasChildren--この属性の存在は、メールボックスには子供メールボックスがあるのを示します。

   Servers SHOULD NOT return \HasChildren if child mailboxes exist, but
   none will be displayed to the current user in a LIST response (as
   should be the case where child mailboxes exist, but a client does not
   have permissions to access them.)  In this case, \HasNoChildren
   SHOULD be used.

子供メールボックスが存在しているなら、サーバSHOULD NOTは\HasChildrenを返しますが、なにもLIST応答では現在のユーザに表示されないでしょう(そうであるべきであるように子供メールボックスが存在していますが、クライアントがそれらにアクセスする許容を持っていない)。 この場合\HasNoChildren SHOULD、使用されてください。

   In many cases, however, a server may not be able to efficiently
   compute whether a user has access to all child mailboxes, or multiple
   users may be accessing the same account and simultaneously changing
   the mailbox hierarchy.  As such a client MUST be prepared to accept
   the \HasChildren attribute as a hint.  That is, a mailbox MAY be
   flagged with the \HasChildren attribute, but no child mailboxes will
   appear in a subsequent LIST response.

しかしながら、ユーザがすべての子供メールボックスに近づく手段を持っているか否かに関係なく、多くの場合、サーバが効率的に計算できないかもしれないか、複数のユーザが、同じアカウントにアクセスして、同時に、メールボックス階層構造を変えるかもしれません。 そういうものとして、クライアントはHasChildrenがヒントとみなす\を受け入れる用意ができていなければなりません。 すなわち、メールボックスはHasChildrenが結果と考える\で旗を揚げられるかもしれませんが、子供メールボックスは全くその後のLIST応答では現れないでしょう。

Gahrns, et al.               Informational                      [Page 2]

RFC 3348             IMAP4 Child Mailbox Extension             July 2002

Gahrns、他 [2ページ]情報のRFC3348IMAP4子供メールボックス拡大2002年7月

   Example 3.1:
   ============

例3.1: ============

   /*** Consider a server that has the following mailbox hierarchy:

/***は以下のメールボックス階層構造を持っているサーバを考えます:

   INBOX
   ITEM_1
      ITEM_1A
   ITEM_2
      TOP_SECRET

受信トレイ項目_1項目_1A項目_2先端_秘密

   Where INBOX, ITEM_1 and ITEM_2 are top level mailboxes.  ITEM_1A is a
   child mailbox of ITEM_1 and TOP_SECRET is a child mailbox of ITEM_2
   that the currently logged on user does NOT have access to.

受信トレイ、ITEM_1、およびITEM_2がトップ平らなメールボックスであるところ。 ITEM_1AはITEM_1の子供メールボックスです、そして、TOP_SECRETは現在ユーザの上に登録されているのが近づく手段を持っていないITEM_2の子供メールボックスです。

   Note that in this case, the server is not able to efficiently compute
   access rights to child mailboxes and responds with a \HasChildren
   attribute for mailbox ITEM_2, even though ITEM_2/TOP_SECRET does not
   appear in the list response.  ***/

サーバがこの場合効率的に子供メールボックスにアクセス権を計算できないで、メールボックスITEM_2のために\HasChildren属性で反応することに注意してください、ITEM_2/TOP_SECRETはリスト応答では現れませんが。 ***/

   C: A001 LIST "" *
   S: * LIST (\HasNoChildren) "/" INBOX
   S: * LIST (\HasChildren) "/" ITEM_1
   S: * LIST (\HasNoChildren) "/" ITEM_1/ITEM_1A
   S: * LIST (\HasChildren) "/" ITEM_2
   S: A001 OK LIST Completed

C: A001が記載する、「「*S:」 * 「」 (\HasNoChildren)/を記載してください」という受信トレイS: * 」 項目_1秒間の「リスト(\HasChildren)」/: * 」 「リスト(\HasNoChildren)」/項目_1/項目_1A S: * 」 項目_2秒間の「リスト(\HasChildren)」/: 完成したA001OKリスト

   \HasNoChildren - The presence of this attribute indicates that the
   mailbox has NO child mailboxes that are accessible to the currently
   authenticated user.  If a mailbox has the \Noinferiors attribute, the
   \HasNoChildren attribute is redundant and SHOULD be omitted in the
   LIST response.

\HasNoChildren--この属性の存在は、メールボックスにはどんな現在認証されたユーザにとって、アクセスしやすい子供メールボックスもないのを示します。 メールボックスにNoinferiorsが結果と考える\があるなら、HasNoChildrenが結果と考える\が余分である、SHOULD、LIST応答では、省略されてください。

   In some instances a server that supports the CHILDREN extension MAY
   NOT be able to determine whether a mailbox has children.  For example
   it may have difficulty determining whether there are child mailboxes
   when LISTing mailboxes while operating in a particular namespace.

ある場合にCHILDRENが拡大であるとサポートするサーバは、メールボックスには子供がいるかどうか決定できないかもしれません。 LISTingメールボックスであるときに、子供メールボックスが特定の名前空間で作動している間、あるかどうか決定するのに例えば、それは苦労するかもしれません。

   In these cases, a server MAY exclude both the \HasChildren and
   \HasNoChildren attributes in the LIST response.  As such, a client
   can not make any assumptions about whether a mailbox has children
   based upon the absence of a single attribute.

これらの場合では、サーバはLIST応答における、\HasChildrenと\HasNoChildren属性の両方を除くかもしれません。 そういうものとして、クライアントは子供がメールボックスでただ一つの属性の欠如に基づいているかどうかに関する少しの仮定もすることができません。

   It is an error for the server to return both a \HasChildren and a
   \HasNoChildren attribute in a LIST response.

それはサーバがLIST応答における、\HasChildrenと\HasNoChildren属性の両方を返す誤りです。

Gahrns, et al.               Informational                      [Page 3]

RFC 3348             IMAP4 Child Mailbox Extension             July 2002

Gahrns、他 [3ページ]情報のRFC3348IMAP4子供メールボックス拡大2002年7月

   It is an error for the server to return both a \HasChildren and a
   \NoInferiors attribute in a LIST response.

それはサーバがLIST応答における、\HasChildrenと\NoInferiors属性の両方を返す誤りです。

   Note: the \HasNoChildren attribute should not be confused with the
   IMAP4 [RFC-2060] defined attribute \Noinferiors which indicates that
   no child mailboxes exist now and none can be created in the future.

以下に注意してください。 HasNoChildrenが結果と考える\は子供メールボックスが全く現在存在しないのを示すIMAP4[RFC-2060]定義された属性\Noinferiorsに混乱するべきではありません、そして、将来、なにも作成できません。

   The \HasChildren and \HasNoChildren attributes might not be returned
   in response to a LSUB response.  Many servers maintain a simple
   mailbox subscription list that is not updated when the underlying
   mailbox structure is changed.  A client MUST NOT assume that
   hierarchy information will be maintained in the subscription list.

属性がLSUB応答に対応して返されないかもしれない\HasChildrenと\HasNoChildren。 多くのサーバが基本的なメールボックス構造を変えるときアップデートしない簡単なメールボックス株式申込者名簿を維持します。 クライアントは、階層構造情報が株式申込者名簿で保守されると仮定してはいけません。

   RLIST is a command defined in [RFC-2193] that includes in a LIST
   response mailboxes that are accessible only via referral.  That is, a
   client must explicitly issue an RLIST command to see a list of these
   mailboxes.  Thus in the case where a mailbox has child mailboxes that
   are available only via referral, the mailboxes would appear as
   \HasNoChildren in response to the LIST command, and \HasChildren in
   response to the RLIST command.

RLISTはLISTに単に紹介でアクセスしやすい応答メールボックスを含んでいる[RFC-2193]で定義されたコマンドです。 すなわち、クライアントは明らかにこれらのメールボックスのリストを見るRLISTコマンドを発行しなければなりません。 したがって、LISTに対応した\HasNoChildrenが命令するようにメールボックスが単に紹介で利用可能な子供メールボックスを持っている場合では、メールボックスは見えるでしょう、そして、RLISTに対応した\HasChildrenは命令します。

5. Formal Syntax

5. 正式な構文

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].

以下の構文仕様は[ABNF]で説明されるように増大しているBN記法(BNF)を使用します。

   Two new mailbox attributes are defined as flag_extensions to the
   IMAP4 mailbox_list response:

2つの新しいメールボックス属性がIMAP4メールボックス_リスト応答への旗_拡大と定義されます:

   HasChildren = "\HasChildren"

「HasChildrenは」 \HasChildrenと等しいです」

   HasNoChildren = "\HasNoChildren"

「HasNoChildrenは」 \HasNoChildrenと等しいです」

6. Security Considerations

6. セキュリティ問題

   This extension provides a client a more efficient means of
   determining whether a particular mailbox has children.  If a mailbox
   has children, but the currently authenticated user does not have
   access to any of them, the server SHOULD respond with a
   \HasNoChildren attribute.  In many cases, however, a server may not
   be able to efficiently compute whether a user has access to all child
   mailboxes.  If such a server responds with a \HasChildren attribute,
   when in fact the currently authenticated user does not have access to
   any child mailboxes, potentially more information is conveyed about
   the mailbox than intended.  A server designed with such levels of
   security in mind SHOULD NOT attach the \HasChildren attribute to a
   mailbox unless the server is certain that the user has access to at
   least one of the child mailboxes.

この拡大は特定のメールボックスには子供がいるかどうか決定するより効率的な手段をクライアントに提供します。 メールボックスには子供がいますが、現在認証されたユーザが彼らのいずれにも近づく手段を持っていないなら、サーバSHOULDは\HasNoChildren属性で応じます。 多くの場合、しかしながら、ユーザがすべての子供メールボックスに近づく手段を持っているか否かに関係なく、サーバは効率的に計算できないかもしれません。 事実上、現在認証されたユーザがどんな子供メールボックスにも近づく手段を持っていないとき、そのようなサーバが\HasChildren属性で反応するなら、潜在的により多くの情報が意図するよりメールボックスの周りで伝えられます。 そのようなレベルのセキュリティが念頭にある状態で、サーバはSHOULD NOTを設計しました。サーバがユーザが少なくとも子供メールボックスの1つに近づく手段を持っているのを確信していない場合、HasChildrenがメールボックスの結果と考える\を付けてください。

Gahrns, et al.               Informational                      [Page 4]

RFC 3348             IMAP4 Child Mailbox Extension             July 2002

Gahrns、他 [4ページ]情報のRFC3348IMAP4子供メールボックス拡大2002年7月

7. References

7. 参照

   [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 2060, December 1996.

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

   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC-2234] Crocker, D. and P. Overell, Editors, "Augmented BNF for
              Syntax Specifications: ABNF", RFC 2234, November 1997.

[RFC-2234]クロッカー、D.とP.Overell、エディターズ、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

   [RFC-2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September
              1997.

[RFC-2193] Gahrns、M.、「IMAP4メールボックス紹介」、RFC2193、1997年9月。

8.  Acknowledgments

8. 承認

   The authors would like to thank the participants of several IMC Mail
   Connect events for their input when this idea was originally
   presented and refined.

この考えが元々、提示されて、洗練されたとき、作者は彼らの入力について数回のIMCメールConnectイベントの関係者に感謝したがっています。

9. Author's Address

9. 作者のアドレス

   Mike Gahrns
   Microsoft
   One Microsoft Way
   Redmond, WA, 98052
   Phone: (425) 936-9833
   EMail: mikega@microsoft.com

レッドモンド、ワシントン、98052が以下に電話をするマイクGahrnsマイクロソフト1マイクロソフト方法 (425) 936-9833 メールしてください: mikega@microsoft.com

   Raymond Cheng
   Microsoft
   One Microsoft Way
   Redmond, WA, 98052
   Phone: (425) 703-4913
   EMail: raych@microsoft.com

レッドモンド、ワシントン、98052が以下に電話をするレイモンドチェンマイクロソフト1マイクロソフト方法 (425) 703-4913 メールしてください: raych@microsoft.com

Gahrns, et al.               Informational                      [Page 5]

RFC 3348             IMAP4 Child Mailbox Extension             July 2002

Gahrns、他 [5ページ]情報のRFC3348IMAP4子供メールボックス拡大2002年7月

10. Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

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

Gahrns, et al.               Informational                      [Page 6]

Gahrns、他 情報[6ページ]