[要約] RFC 6851は、IMAPのMOVE拡張機能に関する仕様です。この拡張機能の目的は、メールボックス内のメッセージを効率的に移動するための方法を提供することです。
Internet Engineering Task Force (IETF) A. Gulbrandsen
Request for Comments: 6851
Category: Standards Track N. Freed, Ed.
ISSN: 2070-1721 Oracle
January 2013
Internet Message Access Protocol (IMAP) - MOVE Extension
インターネットメッセージアクセスプロトコル（IMAP）-MOVE拡張
Abstract
概要
This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another.
このドキュメントでは、MOVEとUID MOVEという2つの新しいコマンドで構成されるIMAP拡張機能を定義します。これらのコマンドは、メールボックス間でメッセージを移動するために使用されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6851.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6851で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document defines an IMAP [RFC3501] extension to facilitate moving messages from one mailbox to another. This is accomplished by defining a new MOVE command and extending the UID command to allow UID MOVE.
このドキュメントでは、IMAP [RFC3501]拡張機能を定義して、メールボックス間でのメッセージの移動を容易にしています。これは、新しいMOVEコマンドを定義し、UIDコマンドを拡張してUID MOVEを許可することによって実現されます。
A move function is not provided in the base IMAP specification, so clients have instead had to use a combination of the COPY, STORE, and EXPUNGE commands to perform this very common operation.
移動機能は基本IMAP仕様で提供されていないため、クライアントは代わりにCOPY、STORE、およびEXPUNGEコマンドの組み合わせを使用して、この非常に一般的な操作を実行する必要がありました。
Implementors have long pointed out some shortcomings with this approach. Because the moving of a message is not an atomic process, interruptions can leave messages in intermediate states. Because multiple clients can be accessing the mailboxes at the same time, clients can see messages in intermediate states even without interruptions. If the source mailbox contains other messages that are flagged for deletion, the third step can have the side effect of expunging more than just the set of moved messages. Additionally, servers with certain types of back-end message stores might have efficient ways of moving messages, which don't involve the actual copying of data. Such efficiencies are often not available to the COPY/STORE/EXPUNGE process.
実装者はこのアプローチのいくつかの欠点を長い間指摘してきました。メッセージの移動はアトミックプロセスではないため、割り込みによってメッセージが中間状態になる可能性があります。複数のクライアントが同時にメールボックスにアクセスできるため、クライアントは中断されなくても中間状態のメッセージを見ることができます。移動元のメールボックスに削除のフラグが付けられた他のメッセージが含まれている場合、3番目の手順では、移動されたメッセージのセットだけでなく、それ以上の消去の副作用が生じる可能性があります。さらに、特定のタイプのバックエンドメッセージストアを備えたサーバーには、メッセージを移動する効率的な方法があり、実際のデータのコピーは必要ありません。このような効率は、多くの場合、COPY / STORE / EXPUNGEプロセスでは利用できません。
The MOVE extension is present in any IMAP implementation that returns "MOVE" as one of the supported capabilities to the CAPABILITY command.
MOVE拡張は、CAPABILITYコマンドでサポートされる機能の1つとして「MOVE」を返すすべてのIMAP実装に存在します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Formal syntax is specified using ABNF [RFC5234].
正式な構文は、ABNF [RFC5234]を使用して指定されます。
Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server.
「C：」で始まる行の例はクライアントによって送信され、「S：」で始まる行はサーバーによって送信されます。
Arguments: sequence set mailbox name
引数：シーケンスセットのメールボックス名
Responses: no specific responses for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - move completed
結果：OK-移動が完了しました
NO - move error: can't move those messages or to that name
いいえ-移動エラー：それらのメッセージまたはその名前に移動できません
BAD - command unknown or arguments invalid
BAD-コマンドが不明または引数が無効
This extends the first form of the UID command (see [RFC3501], Section 6.4.8) to add the MOVE command defined above as a valid argument.
これにより、UIDコマンドの最初の形式（[RFC3501]、セクション6.4.8を参照）が拡張され、上記で定義したMOVEコマンドが有効な引数として追加されます。
The MOVE command takes two arguments: a message set (sequence numbers for MOVE, UIDs for UID MOVE) and a named mailbox. Each message included in the set is moved, rather than copied, from the selected (source) mailbox to the named (target) mailbox.
MOVEコマンドは2つの引数を取ります。メッセージセット（MOVEのシーケンス番号、UID MOVEのUID）と名前付きメールボックスです。セットに含まれる各メッセージは、選択された（ソース）メールボックスから指定された（ターゲット）メールボックスにコピーされるのではなく、移動されます。
This means that a new message is created in the target mailbox with a new UID, the original message is removed from the source mailbox, and it appears to the client as a single action. This has the same effect for each message as this sequence:
これは、新しいUIDを使用してターゲットメッセージに新しいメッセージが作成され、元のメッセージがソースメールボックスから削除され、単一のアクションとしてクライアントに表示されることを意味します。これは、各メッセージに対して次のシーケンスと同じ効果があります。
1. [UID] COPY
1. [UID]コピー
2. [UID] STORE +FLAGS.SILENT \DELETED
2. [UID] STORE + FLAGS.SILENT \ DELETED
3. UID EXPUNGE
3. UID消去
Although the effect of the MOVE is the same as the preceding steps, the semantics are not identical: The intermediate states produced by those steps do not occur, and the response codes are different. In particular, though the COPY and EXPUNGE response codes will be returned, response codes for a STORE MUST NOT be generated and the \DELETED flag MUST NOT be set for any message.
MOVEの効果は前のステップと同じですが、セマンティクスは同じではありません。これらのステップによって生成される中間状態は発生せず、応答コードが異なります。特に、COPYおよびEXPUNGE応答コードが返されますが、STOREの応答コードは生成してはならず（MUST NOT）、\ DELETEDフラグをメッセージに設定してはなりません（MUST NOT）。
Because a MOVE applies to a set of messages, it might fail partway through the set. Regardless of whether the command is successful in moving the entire set, each individual message SHOULD either be moved or unaffected. The server MUST leave each message in a state where it is in at least one of the source or target mailboxes (no message can be lost or orphaned). The server SHOULD NOT leave any message in both mailboxes (it would be bad for a partial failure to result in a bunch of duplicate messages). This is true even if the server returns a tagged NO response to the command.
MOVEはメッセージのセットに適用されるため、セットの途中で失敗する可能性があります。コマンドがセット全体の移動に成功したかどうかに関係なく、個々のメッセージは移動するか影響を受けないようにする必要があります。サーバーは、各メッセージをソースまたはターゲットのメールボックスの少なくとも1つにある状態で残さなければなりません（メッセージが失われたり孤立することはありません）。サーバーは両方のメールボックスにメッセージを残さないでください（部分的な障害が原因で大量の重複メッセージが発生するのは好ましくありません）。これは、サーバーがコマンドに対してタグ付きのNO応答を返す場合でも当てはまります。
Because of the similarity of MOVE to COPY, extensions that affect COPY affect MOVE in the same way. Response codes such as TRYCREATE (see [RFC3501], Section 6.4.7), as well as those defined by extensions, are sent as appropriate. See Section 4 for more information about how MOVE interacts with other IMAP extensions.
MOVEはCOPYと類似しているため、COPYに影響を与える拡張機能はMOVEにも同じように影響します。 TRYCREATE（[RFC3501]、セクション6.4.7を参照）などの応答コードと、拡張機能によって定義されたコードが、必要に応じて送信されます。 MOVEが他のIMAP拡張機能と相互作用する方法の詳細については、セクション4を参照してください。
An example:
例：
C: a UID MOVE 42:69 foo
S: * OK [COPYUID 432432 42:69 1202:1229]
S: * 22 EXPUNGE
S: (more expunges)
S: a OK Done
Note that the server may send unrelated EXPUNGE responses as well, if any happen to have been expunged at the same time; this is normal IMAP operation.
同時に消去された場合、サーバーは無関係のEXPUNGE応答も送信する場合があることに注意してください。これは通常のIMAP操作です。
Implementers will need to read [RFC4315] to understand what UID EXPUNGE does, though full implementation of [RFC4315] is not necessary.
[RFC4315]の完全な実装は必要ありませんが、実装者はUID EXPUNGEの機能を理解するために[RFC4315]を読む必要があります。
Note that moving a message to the currently selected mailbox (that is, where the source and target mailboxes are the same) is allowed when copying the message to the currently selected mailbox is allowed.
現在選択されているメールボックスへのメッセージのコピーが許可されている場合、メッセージを現在選択されているメールボックス（つまり、ソースとターゲットのメールボックスが同じ場所）に移動できることに注意してください。
The server may send EXPUNGE (or VANISHED) responses before the tagged response, so the client cannot safely send more commands with message sequence number arguments while the server is processing MOVE or UID MOVE.
サーバーはタグ付けされた応答の前にEXPUNGE（またはVANISHED）応答を送信する可能性があるため、サーバーがMOVEまたはUID MOVEを処理している間、クライアントはメッセージシーケンス番号引数を含むコマンドを安全に送信できません。
Both MOVE and UID MOVE can be pipelined with other commands, but care has to be taken. Both commands modify sequence numbers and also allow unrelated EXPUNGE responses. The renumbering of other messages in the source mailbox following any EXPUNGE response can be surprising and makes it unsafe to pipeline any command that relies on message sequence numbers after a MOVE or UID MOVE. Similarly, MOVE cannot be pipelined with a command that might cause message renumbering. See [RFC3501], Section 5.5, for more information about ambiguities as well as handling requirements for both clients and servers.
MOVEとUID MOVEはどちらも他のコマンドでパイプライン処理できますが、注意が必要です。どちらのコマンドもシーケンス番号を変更し、関連のないEXPUNGE応答も許可します。 EXPUNGE応答に続くソースメールボックス内の他のメッセージの再番号付けは驚くべきことであり、MOVEまたはUID MOVEの後にメッセージシーケンス番号に依存するコマンドをパイプライン処理するのは安全ではありません。同様に、MOVEは、メッセージの再番号付けを引き起こす可能性のあるコマンドでパイプライン処理することはできません。あいまいさ、およびクライアントとサーバーの両方の処理要件の詳細については、[RFC3501]、セクション5.5を参照してください。
This section describes how MOVE interacts with some other IMAP extensions.
このセクションでは、MOVEが他のIMAP拡張機能とどのように相互作用するかについて説明します。
The QUOTA extension (defined by [RFC2087]) may interact with MOVE on some servers, in the sense that a MOVE command may succeed where COPY would cause a quota overrun.
QUOTA拡張（[RFC2087]で定義）は、COPYがクォータオーバーランを引き起こす場合にMOVEコマンドが成功するという意味で、一部のサーバーのMOVEと相互作用する場合があります。
The ACL rights [RFC4314] required for MOVE and UID MOVE are the union of the ACL rights required for UID STORE, UID COPY, and UID EXPUNGE.
MOVEおよびUID MOVEに必要なACL権利[RFC4314]は、UID STORE、UID COPY、およびUID EXPUNGEに必要なACL権利の和集合です。
Servers supporting UIDPLUS [RFC4315] SHOULD send COPYUID in response to a UID MOVE command. For additional information see Section 3 of [RFC4315].
UIDPLUS [RFC4315]をサポートするサーバーは、UID MOVEコマンドへの応答としてCOPYUIDを送信する必要があります（SHOULD）。追加情報については、[RFC4315]のセクション3を参照してください。
Servers implementing UIDPLUS are also advised to send the COPYUID response code in an untagged OK before sending EXPUNGE or moved responses. (Sending COPYUID in the tagged OK, as described in the UIDPLUS specification, means that clients first receive an EXPUNGE for a message and afterwards COPYUID for the same message. It can be unnecessarily difficult to process that sequence usefully.)
UIDPLUSを実装するサーバーは、EXPUNGEまたは移動された応答を送信する前に、タグなしOKでCOPYUID応答コードを送信することもお勧めします。 （UIDPLUS仕様で説明されているように、タグ付きOKでCOPYUIDを送信することは、クライアントが最初にメッセージのEXPUNGEを受信し、その後同じメッセージのCOPYUIDを受信することを意味します。そのシーケンスを有効に処理することが不必要に難しい場合があります。）
The QRESYNC extension [RFC5162] states that the server SHOULD send VANISHED rather than EXPUNGE in response to the UID EXPUNGE command. The same requirement applies to MOVE, and a QRESYNC-enabled client needs to handle both VANISHED and EXPUNGE responses to a UID MOVE command.
QRESYNC拡張[RFC5162]は、サーバーがUID EXPUNGEコマンドへの応答としてEXPUNGEではなくVANISHEDを送信する必要があることを示しています。同じ要件がMOVEにも適用され、QRESYNC対応クライアントは、UID MOVEコマンドに対するVANISHED応答とEXPUNGE応答の両方を処理する必要があります。
If the server is capable of storing modification sequences for the selected mailbox, it MUST increment the per-mailbox mod-sequence if at least one message was permanently moved due to the execution of the MOVE/UID MOVE command. For each permanently removed message, the server MUST remember the incremented mod-sequence and corresponding UID. If at least one message was moved, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [RFC4551]) in the tagged or untagged OK response.
サーバーが選択したメールボックスの変更シーケンスを保存できる場合、MOVE / UID MOVEコマンドの実行により少なくとも1つのメッセージが永続的に移動された場合、メールボックスごとのmodシーケンスをインクリメントする必要があります。完全に削除されたメッセージごとに、サーバーはインクリメントされたmodシーケンスと対応するUIDを記憶する必要があります。少なくとも1つのメッセージが移動された場合、サーバーはタグ付きまたはタグなしOK応答でHIGHESTMODSEQ応答コード（[RFC4551]で定義）を使用して、更新されたメールボックスごとの変更シーケンスを送信する必要があります。
When one or more messages are moved to a target mailbox, if the server is capable of storing modification sequences for the mailbox, the server MUST generate and assign new modification sequence numbers to the moved messages that are higher than the highest modification sequence of the messages originally in the mailbox.
1つ以上のメッセージがターゲットメールボックスに移動されたときに、サーバーがメールボックスの変更シーケンスを格納できる場合、サーバーは、メッセージの最高の変更シーケンスよりも大きい新しい変更シーケンス番号を生成して、移動されたメッセージに割り当てる必要があります。もともとはメールボックスにあります。
MOVE applies to IMAP events in Sieve [RFC6785] in the same way as COPY does. Therefore, MOVE can cause a Sieve script to be invoked with the imap.cause set to "COPY". Because MOVE does not cause flags to be changed, a MOVE command will not result in a script invocation with the imap.cause set to "FLAG".
MOVEは、COPYと同じ方法でSieve [RFC6785]のIMAPイベントに適用されます。したがって、MOVEにより、imap.causeを "COPY"に設定してSieveスクリプトを呼び出すことができます。 MOVEによってフラグが変更されることはないため、MOVEコマンドを実行しても、imap.causeが "FLAG"に設定されたスクリプトは呼び出されません。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability", "command-select", "sequence-set", and "mailbox".
次の構文仕様は、[RFC5234]で指定されているAugmented Backus-Naur Form（ABNF）表記を使用しています。 [RFC3501]は、非端末の「機能」、「コマンド選択」、「シーケンスセット」、および「メールボックス」を定義します。
Except as noted otherwise, all alphabetic characters are case insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特に明記しない限り、すべてのアルファベット文字は大文字と小文字を区別しません。トークン文字列を定義するための大文字または小文字の使用は、編集上の明確さのためだけです。実装は、大文字と小文字を区別しない方法でこれらの文字列を受け入れる必要があります。
capability =/ "MOVE"
機能= / "MOVE"
command-select =/ move
move = "MOVE" SP sequence-set SP mailbox
uid = "UID" SP (copy / fetch / search / store / move)
MOVE does not introduce any new capabilities to IMAP, and this limits the security impact. However, the transactional semantics of MOVE may interact with specific implementations in ways that could have unexpected consequences. For example, moving messages between mailboxes under the quota root may require temporary suspension of quota checking.
MOVEはIMAPに新しい機能を導入しないため、セキュリティへの影響が制限されます。ただし、MOVEのトランザクションセマンティクスは、予期しない結果をもたらす可能性のある方法で特定の実装と相互作用する場合があります。たとえば、クォータルートの下のメールボックス間でメッセージを移動するには、クォータチェックを一時的に停止する必要がある場合があります。
An additional area of concern is interaction with antispam, antivirus, and other security scanning and auditing mechanisms. Different mailboxes may have different security policies that could interact with MOVE in complex ways. Scanning with updated rules may also be required when messages are moved even when the underlying policy has not changed.
懸念される追加の領域は、スパム対策、ウイルス対策、およびその他のセキュリティスキャンおよび監査メカニズムとの相互作用です。メールボックスごとに異なるセキュリティポリシーがあり、MOVEと複雑な方法で相互作用する可能性があります。基になるポリシーが変更されていない場合でも、メッセージが移動された場合は、更新されたルールによるスキャンが必要になる場合があります。
MOVE does relieve a problem with the base specification, since client authors currently have to devise and implement complicated algorithms to handle partial failures of the STORE/COPY/EXPUNGE trio. Incomplete or improper implementation of these algorithms can lead to mail loss.
クライアントの作成者は現在、STORE / COPY / EXPUNGEトリオの部分的な障害を処理するために複雑なアルゴリズムを考案して実装する必要があるため、MOVEは基本仕様の問題を緩和します。これらのアルゴリズムの実装が不完全または不適切であると、メールが失われる可能性があります。
The IANA has added MOVE to the "IMAP 4 Capabilities" registry, <http://www.iana.org/assignments/imap4-capabilities>.
IANAはMOVEを「IMAP 4機能」レジストリ<http://www.iana.org/assignments/imap4-capabilities>に追加しました。
This document is dedicated to the memory of Mark Crispin, the inventor of the IMAP protocol, author of the IMAP protocol specification [RFC3501], and contributor to many other email specifications in the IETF.
このドキュメントは、IMAPプロトコルの発明者であり、IMAPプロトコル仕様[RFC3501]の作者であり、IETFの他の多くの電子メール仕様に貢献したMark Crispinの記憶に捧げられています。
An extension like this has been proposed many times, by many people. This document is based on several of those proposals, most recently that by Witold Krecicki. Witold, Benoit Claise, Adrien W. de Croy, Stephen Farrell, Bron Gondwana, Dan Karp, Christian Ketterer, Murray Kucherawy, Jan Kundrat, Barry Leiba, Alexey Melnikov, Kathleen Moriarty, Zoltan Ordogh, Pete Resnick, Timo Sirainen, Michael Slusarz, and others provided valuable comments.
このような拡張機能は、多くの人から何度も提案されてきました。この文書は、最近のWitold Krecickiによる提案のいくつかに基づいています。ウィトールド、ブノワクレイズ、エイドリアンW.デクロイ、スティーブンファレル、ブロンゴンドワナ、ダンカルプ、クリスチャンケタラー、マレークチェラウィ、ヤンクンドラット、バリーレイバ、アレクセイメルニコフ、キャスリーンモリアーティ、ゾルタンオルドッグ、ピートレズニック、ティモシレイネン、マイケルスルサーズ、他の人から貴重なコメントがありました
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、2003年3月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314] Melnikov、A。、「IMAP4 Access Control List（ACL）Extension」、RFC 4314、2005年12月。
[RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[RFC4315] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP）-UIDPLUS拡張」、RFC 4315、2005年12月。
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[RFC4551] Melnikov、A。およびS. Hole、「条件付きSTORE操作またはクイックフラグ変更の再同期のためのIMAP拡張」、RFC 4551、2006年6月。
[RFC5162] Melnikov, A., Cridland, D., and C. Wilson, "IMAP4 Extensions for Quick Mailbox Resynchronization", RFC 5162, March 2008.
[RFC5162] Melnikov、A.、Cridland、D。、およびC. Wilson、「IMAP4 Extensions for Quick Mailbox Resynchronization」、RFC 5162、2008年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997.
[RFC2087]マイヤーズJ。、「IMAP4 QUOTA拡張機能」、RFC 2087、1997年1月。
[RFC6785] Leiba, B., "Support for Internet Message Access Protocol (IMAP) Events in Sieve", RFC 6785, November 2012.
[RFC6785] Leiba、B。、「Support for Internet Message Access Protocol（IMAP）Events in Sieve」、RFC 6785、2012年11月。
Authors' Addresses
著者のアドレス
Arnt Gulbrandsen Schweppermannstr. 8 D-81671 Muenchen Germany
Arnt Gulbrandsen Schweppermannstr。 8 D-81671ミュンヘンドイツ
Fax: +49 89 4502 9758
EMail: arnt@gulbrandsen.priv.no
Ned Freed (editor) Oracle 800 Royal Oaks Monrovia, CA 91016-6347 USA
Ned Freed（editor）Oracle 800 Royal Oaks Monrovia、CA 91016-6347 USA
EMail: ned+ietf@mrochek.com