[要約] RFC 2442は、バッチSMTPメディアタイプの仕様を定義しています。このRFCの目的は、複数のメールを一度に送信するための効率的な方法を提供することです。
Network Working Group N. Freed
Request for Comments: 2442 D. Newman
Category: Informational Innosoft
J. Belissent
Sun Microsystems
M. Hoy
Mainbrace
November 1998
The Batch SMTP Media Type
バッチSMTPメディアタイプ
Status of this 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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document defines a MIME content type suitable for tunneling an ESMTP [RFC-821, RFC-1869] transaction through any MIME-capable transport. This type can be used for a variety of purposes, including: Extending end-to-end MIME-based security services (e.g., [RFC-1847]) to cover message envelope information as well as message content. Making it possible to use specific SMTP extensions such as NOTARY [RFC-1891] over unextended SMTP transport infrastructure. Enabling the transfer of multiple separate messages in a single transactional unit.
このドキュメントでは、MIME対応のトランスポートを介してESMTP [RFC-821、RFC-1869]トランザクションをトンネリングするのに適したMIMEコンテンツタイプを定義しています。このタイプは、次のようなさまざまな目的に使用できます。メッセージエンベロープ情報とメッセージコンテンツをカバーするためのエンドツーエンドMIMEベースのセキュリティサービス（[RFC-1847]など）の拡張。非拡張SMTPトランスポートインフラストラクチャ上でNOTARY [RFC-1891]などの特定のSMTP拡張機能を使用できるようにします。単一のトランザクション単位で複数の個別のメッセージの転送を可能にします。
Requirements Notation
要件表記
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]; the terms "MUST NOT" and "SHOULD NOT" are logical extensions of this usage.
このドキュメントでは、大文字で表示される用語を使用することがあります。 「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」という用語は、大文字で表記されている場合、この仕様の特定の要件を示すために使用されています。 「MUST」、「SHOULD」、「MAY」という用語の意味についての議論は、[RFC-1123]にあります。 「MUST NOT」および「SHOULD NOT」という用語は、この使用法の論理的な拡張です。
The Application/batch-SMTP Content Type
アプリケーション/バッチSMTPコンテンツタイプ
The "application/batch-SMTP" MIME content type is a container for the client side of an SMTP or ESMTP transaction. In keeping with traditional SMTP, the contents are line oriented and CRLF line terminators MUST be used.
「application / batch-SMTP」MIMEコンテンツタイプは、SMTPまたはESMTPトランザクションのクライアント側のコンテナです。従来のSMTPに合わせて、内容は行指向であり、CRLF行ターミネーターを使用する必要があります。
The "application/batch-SMTP" type is defined as follows:
「application / batch-SMTP」タイプは次のように定義されます。
Media type name: application Media subtype name: batch-SMTP Required parameters: none Optional parameters: required-extensions Encoding considerations: 8bit material may appear, so quoted-printable or base64 encoding may be necessary on transports that do not support 8bit. While the content of this type is line-oriented and uses conventional CR/LF terminators, lines longer than 7bit and 8bit encodings allow (998 octets) may appear, hence quoted-printable or base64 encoding may be necessary even in conjunction with 8bit transports. Security considerations: Discussed in the Security Considerations Section.
メディアタイプ名：アプリケーションメディアサブタイプ名：batch-SMTP必須パラメーター：なしオプションパラメーター：required-extensionsエンコードに関する考慮事項：8ビットの素材が表示される場合があるため、8ビットをサポートしないトランスポートではquoted-printableまたはbase64エンコードが必要になる場合があります。このタイプのコンテンツは行指向であり、従来のCR / LFターミネータを使用しますが、7ビットおよび8ビットエンコーディングで許可される（998オクテット）より長い行が表示される場合があるため、8ビットトランスポートと組み合わせてもquoted-printableまたはbase64エンコーディングが必要になる場合があります。セキュリティに関する考慮事項：「セキュリティに関する考慮事項」セクションで説明します。
How application/batch-SMTP is used
アプリケーション/バッチSMTPの使用方法
The following diagram illustrates how the application/batch-SMTP type is intended to be used:
次の図は、application / batch-SMTPタイプの使用方法を示しています。
application/batch-SMTP object
+----------------+
| |
+-----------+ v +----------+ v +-----------+
| batch | | MIME- | | batch |
=> | SMTP | => | capable | => | SMTP | =>
| generator | |transport | | processor |
^ +-----------+ +----------+ +-----------+ ^
| |
+-- conventional SMTP/RFC822 message transaction --+
A conventional SMTP message transaction is converted into an application/batch-SMTP object by the batch SMTP generator. This object is then carried over some type of MIME-capable transport. Once the destination is reached the object is presented to a batch SMTP processor, which converts the application/batch-SMTP object back into a conventional SMTP message transaction.
従来のSMTPメッセージトランザクションは、バッチSMTPジェネレーターによってapplication / batch-SMTPオブジェクトに変換されます。その後、このオブジェクトは、何らかのタイプのMIME対応トランスポートを介して運ばれます。宛先に到達すると、オブジェクトはバッチSMTPプロセッサに提示され、アプリケーション/バッチSMTPオブジェクトを従来のSMTPメッセージトランザクションに変換します。
Generation of application/batch-SMTP material
アプリケーション/バッチSMTPマテリアルの生成
Application/batch-SMTP material is generated by a specially modified SMTP client operating without a corresponding SMTP server. The client simply assumes a successful response to all commands it issues. The resulting content then consists of the collected output from the SMTP client.
アプリケーション/バッチSMTPマテリアルは、対応するSMTPサーバーなしで動作する特別に変更されたSMTPクライアントによって生成されます。クライアントは、発行するすべてのコマンドに対する応答が成功したと見なします。結果のコンテンツは、SMTPクライアントから収集された出力で構成されます。
Honoring SMTP restrictions
SMTP制限の遵守
Most batch SMTP processors will be constructed by modifying and extending existing SMTP servers. As such, all of the restrictions on SMTP constructs imposed by RFC 821, RFC 1123, and RFC 1869 MUST be observed. In particular, restrictions on command and data line lengths, number of recipients, and so on still exist and apply to batch SMTP.
ほとんどのバッチSMTPプロセッサは、既存のSMTPサーバーを変更および拡張することによって構築されます。そのため、RFC 821、RFC 1123、およびRFC 1869によって課されるSMTPコンストラクトのすべての制限を遵守する必要があります。特に、コマンドとデータの行の長さ、受信者の数などの制限は依然として存在し、バッチSMTPに適用されます。
Use of SMTP Extensions
SMTP拡張機能の使用
Since no SMTP server is present the client must be prepared to make certain assumptions about which SMTP extensions can be used. The generator MAY assume that ESMTP [RFC-1869] facilities are available, that is, it is acceptable to use the EHLO command and additional parameters on MAIL FROM and RCPT TO. If EHLO is used MAY assume that the 8bitMIME [RFC-1652], SIZE [RFC-1870], and NOTARY [RFC-1891] extensions are available. In particular, NOTARY SHOULD be used. MAY create private bilateral agreements which specify the availability of additional SMTP extensions. Additional SMTP extensions MUST NOT be used in the absence of such an agreement, and, perhaps more importantly, a conformant generation of application/batch-SMTP objects MUST be able to produce objects restricted to use of the extensions listed above.
SMTPサーバーが存在しないため、クライアントは、どのSMTP拡張機能を使用できるかについて特定の仮定を行う準備をする必要があります。ジェネレータは、ESMTP [RFC-1869]機能が利用可能であると想定してもよい（MAY FROMおよびRCPT TOでEHLOコマンドと追加のパラメータを使用することは許容される）。 EHLOが使用される場合、8bitMIME [RFC-1652]、SIZE [RFC-1870]、およびNOTARY [RFC-1891]拡張が利用可能であると想定してもよい（MAY）。特に、NOTARY SHOULDを使用する必要があります。追加のSMTP拡張機能の可用性を指定するプライベートな二国間協定を作成する場合があります。そのような合意がない場合、追加のSMTP拡張機能を使用してはならず（MUST NOT）、おそらくより重要なこととして、アプリケーション/バッチSMTPオブジェクトの適合世代は、上記の拡張機能の使用に制限されたオブジェクトを生成できなければなりません（MUST）。
The "required-extensions" content type parameter MAY be used to communicate a list of the extensions actually used, specified as a comma-separated list of EHLO responses. If absent it defaults to the list "8bitMIME,SIZE,NOTARY". Any use by private bilateral agreement of additional or different extensions MUST be noted in the "required-extensions" parameter.
「required-extensions」コンテンツタイプパラメータは、EHLO応答のコンマ区切りリストとして指定された、実際に使用される拡張機能のリストを通信するために使用される場合があります。指定しない場合、デフォルトでリスト「8bitMIME、SIZE、NOTARY」になります。追加または異なる拡張の私的二国間協定による使用は、「required-extensions」パラメーターに記載する必要があります。
Note that many SMTP extensions simply do not make sense in the context of batch SMTP. For example, the pipelining extension [RFC-2197] makes no sense in the absence of a network connection.
多くのSMTP拡張機能は、バッチSMTPのコンテキストでは意味をなさないことに注意してください。たとえば、パイプライン拡張[RFC-2197]は、ネットワーク接続がないと意味がありません。
Handling Multiple Messages
複数のメッセージの処理
Generators SHOULD attempt to minimize the number of messages placed in a single application/batch-SMTP object. Ideally a single application/batch-SMTP object will be created for each message. Note, however, that some uses of application/batch-SMTP (e.g., mail bagging) may exist solely to take advantage of the multiple messages in a single container capability of batch SMTP, so requiring one message per container is not possible.
ジェネレーターは、単一のアプリケーション/バッチSMTPオブジェクトに配置されるメッセージの数を最小限に抑えるようにする必要があります（SHOULD）。理想的には、メッセージごとに1つのアプリケーション/バッチSMTPオブジェクトが作成されます。ただし、application / batch-SMTPの一部の使用法（メールのバギングなど）は、バッチSMTPの単一のコンテナー機能で複数のメッセージを利用するためにのみ存在する場合があるため、コンテナーごとに1つのメッセージを要求することはできません。
DISCUSSION: The SMTP protocol provides for the transfer of a series of messages over a single connection. This extends in a natural way to batch SMTP. However, the issues in batch SMTP are somewhat different. Suppose, for example, that a batch SMTP processor receives an application/batch-SMTP object containing two messages but is unable to process the second message because of a storage allocation failure. But suppose that not only does this failure preclude processing of the second message, it also precludes recording that the first message has already been processed. Subsequent reprocessing of the application/batch-SMTP could then lead to duplication of the first message.
DISCUSSION：SMTPプロトコルは、単一の接続を介した一連のメッセージの転送を提供します。これは、SMTPをバッチ処理する自然な方法で拡張されます。ただし、バッチSMTPの問題は多少異なります。たとえば、バッチSMTPプロセッサが2つのメッセージを含むapplication / batch-SMTPオブジェクトを受信したが、ストレージの割り当てに失敗したため、2番目のメッセージを処理できないとします。ただし、この障害が2番目のメッセージの処理を妨げるだけでなく、最初のメッセージがすでに処理されたという記録も妨げるとします。その後、アプリケーション/バッチSMTPを再処理すると、最初のメッセージが重複する可能性があります。
This issue is not materially different from the well-known problems with SMTP synchronization that in practice often lead to duplicated messages. Since this behavior is inherent in SMTP to begin with it is not incumbent on application/batch-SMTP to completely address the issue. Nevertheless, it seems prudent for application/batch-SMTP to try and not make matters even worse.
この問題は、実際にはメッセージの重複につながることが多いSMTP同期のよく知られた問題と実質的に違いはありません。この動作はSMTPに本来備わっているため、問題を完全に解決するためのapplication / batch-SMTPの役割はありません。それにもかかわらず、アプリケーション/バッチSMTPが問題をさらに悪化させないようにすることは賢明なようです。
Transport of application/batch-SMTP objects
アプリケーション/バッチSMTPオブジェクトのトランスポート
Application/batch-SMTP objects may be transported by any transport capable of preserving their MIME labelling, e.g., HTTP or SMTP.
アプリケーション/バッチSMTPオブジェクトは、MIMEラベルを保持できる任意のトランスポート（HTTPやSMTPなど）によってトランスポートできます。
Transports MUST remain cognizant of the special nature of application/batch-SMTP. An application/batch-SMTP object contains one or more "frozen" SMTP message transactions. SMTP message transactions typically carry with them various assumptions about quality of service, e.g., that messages will either be delivered successfully or a nondelivery notification will be returned, that a nondelivery notification will be returned if delivery cannot be accomplished in a timely fashion, and so on. It is vital that the encapsulation of these objects for carriage over other forms of transport not interfere with these capabilities.
トランスポートは、application / batch-SMTPの特殊な性質を常に認識している必要があります。アプリケーション/バッチSMTPオブジェクトには、1つ以上の「凍結された」SMTPメッセージトランザクションが含まれています。通常、SMTPメッセージトランザクションには、サービスの品質に関するさまざまな想定が含まれています。たとえば、メッセージは正常に配信されるか、配信不能通知が返されるか、配信がタイムリーに実行できない場合は、配信不能通知が返されます。オン。これらのオブジェクトをカプセル化して他の輸送手段を介して運搬することは、これらの機能を妨げないことが重要です。
Processing of application/batch-SMTP material
アプリケーション/バッチSMTPマテリアルの処理
Processing of application/batch-SMTP material is considerably more complex than generating it. As might be expected, a modified SMTP/ESMTP processor is used. However, since it cannot return information to the client, it must handle all error conditions that arise itself. In other words, a batch SMTP processor assumes both the responsibilities of a traditional SMTP server as well as part of the responsibilities of a traditional SMTP client.
アプリケーション/バッチSMTPマテリアルの処理は、生成よりもかなり複雑です。予想通り、変更されたSMTP / ESMTPプロセッサが使用されます。ただし、クライアントに情報を返すことができないため、発生するすべてのエラー条件を処理する必要があります。つまり、バッチSMTPプロセッサは、従来のSMTPサーバーの責任と、従来のSMTPクライアントの責任の両方の両方を想定しています。
As such, a conforming processor: MUST check MIME content type information to insure that the material it has been presented with is labelled as application/batch-SMTP and doesn't specify any extensions the processor doesn't support in the "required-extensions" parameter. Application/batch-SMTP objects that employ an unsupported extension SHOULD be forwarded to the local postmaster for manual inspection and handling. MUST accept any syntactically valid EHLO or HELO command. MUST accept any syntactically valid MAIL FROM command. A conforming processor, MAY, if it so desires, note the unacceptability of some part of a given MAIL FROM command and use this information to subsequently generate non-delivery notifications for any or all recipients. MUST accept any syntactically valid RCPT TO command. A conforming processor SHOULD note the unacceptability of some part of a given RCPT TO command and subsequently use this information to generate a non-delivery notification for this recipient in lieu of actually delivering the message. MUST accept any of the additional parameters defined by the 8bitMIME, SIZE, and NOTARY SMTP extensions on the MAIL FROM and RCPT TO commands. MUST accept the DATA command even when no valid recipients are present. 8bit MIME messages MUST be accepted. MUST accept the RSET command and handle multiple messages in a single application/batch-SMTP object. Processors MUST process each message in an application/batch-SMTP object once and SHOULD take whatever steps are necessary to avoid processing a message more than once. For example, if processing of an application/batch-SMTP object containing multiple messages is interrupted at an intermediate point it should subsequently be restarted at the end of the last message that was completely processed. SHOULD forward any syntactically invalid application/batch-SMTP message to the local postmaster for manual inspection and handling.
そのため、適合プロセッサ：MIMEコンテンツタイプ情報を確認して、提示された素材がapplication / batch-SMTPとしてラベル付けされ、プロセッサが「required-extensions」でサポートしていない拡張を指定していないことを確認する必要があります。 "パラメータ。サポートされていない拡張機能を使用するアプリケーション/バッチSMTPオブジェクトは、手動で検査および処理するためにローカルポストマスターに転送する必要があります（SHOULD）。構文的に有効なEHLOまたはHELOコマンドを受け入れる必要があります。構文的に有効なMAIL FROMコマンドを受け入れる必要があります。適合プロセッサは、必要に応じて、特定のMAIL FROMコマンドの一部が受け入れられないことに注意し、この情報を使用して、任意またはすべての受信者に対して配信不能通知を生成します。構文的に有効なRCPT TOコマンドを受け入れる必要があります。適合プロセッサは、特定のRCPT TOコマンドの一部が受け入れられないことに注意し、その後この情報を使用して、実際にメッセージを配信する代わりに、この受信者に配信不能通知を生成します。 MAIL FROMおよびRCPT TOコマンドの8bitMIME、SIZE、およびNOTARY SMTP拡張機能で定義された追加パラメーターのいずれかを受け入れる必要があります。有効な受信者が存在しない場合でも、DATAコマンドを受け入れる必要があります。 8ビットMIMEメッセージを受け入れる必要があります。 RSETコマンドを受け入れ、単一のアプリケーション/バッチSMTPオブジェクトで複数のメッセージを処理する必要があります。プロセッサは、application / batch-SMTPオブジェクト内の各メッセージを1回処理する必要があり、メッセージの複数回の処理を回避するために必要な手順を実行する必要があります（SHOULD）。たとえば、複数のメッセージを含むapplication / batch-SMTPオブジェクトの処理が途中で中断された場合、完全に処理された最後のメッセージの最後から再開する必要があります。構文的に無効なアプリケーション/バッチSMTPメッセージをローカルのポストマスターに転送して、手動で検査および処理する必要があります（SHOULD）。
Security Considerations
セキュリティに関する考慮事項
Application/batch-SMTP implements a tunneling mechanism. In general tunneling mechanisms are prone to abuse because they may provide a means of bypassing existing security restrictions. For example, an application/batch-SMTP tunnel implemented over an existing SMTP transport may allow someone to bypass relay restrictions imposed to block redistribution of spam.
アプリケーション/バッチSMTPは、トンネリングメカニズムを実装しています。一般に、トンネリングメカニズムは既存のセキュリティ制限を回避する手段を提供する可能性があるため、悪用される傾向があります。たとえば、既存のSMTPトランスポート上に実装されたアプリケーション/バッチSMTPトンネルでは、スパムの再配布をブロックするために課されたリレー制限をバイパスすることができます。
Application/batch-SMTP processors SHOULD implement access restrictions designed to limit access to the processor to authorized generators only. (Note that this facility may be provided automatically if application/batch-SMTP is being used to secure message envelope information.)
アプリケーション/バッチSMTPプロセッサは、プロセッサへのアクセスを許可されたジェネレータのみに制限するように設計されたアクセス制限を実装する必要があります（SHOULD）。 （アプリケーション/バッチSMTPがメッセージエンベロープ情報を保護するために使用されている場合、この機能は自動的に提供される可能性があることに注意してください。）
Acknowledgements
謝辞
The general concept of batch SMTP has been around for a long time. One particular type of batch SMTP was defined by Alan Crosswell and used on BITNET to overcome BITNET's native 8 character limit on user and host names. However, this form of batch SMTP differed from the current proposal in that it envisioned having the server return the status code responses to the client. In this case the client bore the burden of correlating responses with the original SMTP dialogue after the fact.
バッチSMTPの一般的な概念は古くからあります。特定のタイプのバッチSMTPはAlan Crosswellによって定義され、ユーザー名とホスト名に対するBITNETのネイティブ8文字制限を克服するためにBITNETで使用されました。ただし、この形式のバッチSMTPは、サーバーがステータスコードの応答をクライアントに返すことを想定しているという点で、現在の提案とは異なります。この場合、クライアントは、事後の応答を元のSMTPダイアログと関連付けるという負担を負っていました。
Unfortunately this approach proved not to work well in practice. BITNET eventually switched to the same basic form of batch SMTP that has been defined here. Unfortunately that definition was, to the best of the present authors' knowledge, never captured in a formal specification. It should also be noted that the definition given here also differs in that it takes SMTP extensions into account.
残念ながら、このアプローチは実際にはうまく機能しないことが判明しました。 BITNETは最終的に、ここで定義されているものと同じ基本形式のバッチSMTPに切り替えました。残念なことに、その定義は、現在の著者の知る限りでは、正式な仕様に取り込まれることはありませんでした。ここでの定義は、SMTP拡張機能を考慮するという点でも異なります。
Einar Stefferud had previously considered the problem of carrying extended SMTP messages over unextended SMTP transports. He proposed that some form of "double enveloping" technology be developed to address this problem. The mechanism presented here effectively implements the type of solution he proposed.
Einar Stefferudは以前、拡張されていないSMTPトランスポートを介して拡張されたSMTPメッセージを運ぶ問題を検討していました。この問題に対処するために、何らかの形の「二重包絡」技術を開発することを提案した。ここで紹介するメカニズムは、彼が提案した種類のソリューションを効果的に実装しています。
References
参考文献
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC-821] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822 August 1982.
[RFC-822] Crocker、D。、「Standard for the Format for ARPA Internet Text Messages」、STD 11、RFC 822 August 1982。
[RFC-1123] Braden, B., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC-1123] Braden、B。、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC-1652] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC-1652] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8ビットMIMEトランスポート用のSMTPサービス拡張」、RFC 1652、1994年7月。
[RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC-1847] Galvin、J.、Murphy、S.、Crocker、S.、N。Freed、「MIMEのセキュリティマルチパート：Multipart / SignedおよびMultipart / Encrypted」、RFC 1847、1995年10月。
[RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[RFC-1869] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。およびD. Crocker、「SMTP Service Extensions」、STD 10、RFC 1869、1995年11月。
[RFC-1870] Klensin, J., Freed, N., Moore, K., "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November, 1995.
[RFC-1870]クレンシンJ.、フリードN.、ムーアK.、「メッセージサイズ宣言のためのSMTPサービス拡張」、STD 10、RFC 1870、1995年11月。
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
[RFC-2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年12月。
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
[RFC-2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年12月。
[RFC-2197] Freed, N. and A. Cargille, "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.
[RFC-2197] Freed、N。およびA. Cargille、「SMTP Service Extension for Command Pipelining」、RFC 2197、1997年9月。
Authors' Addresses
著者のアドレス
Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Ned Freed Innosoft International、Inc. 1050 Lakes Drive West Covina、CA 91790 USA
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.com
Dan Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Dan Newman Innosoft International、Inc. 1050 Lakes Drive West Covina、CA 91790 USA
Phone: +1 626 919 3600 Fax: +1 626 919 3614 EMail: dan.newman@innosoft.com Mark Hoy Mainbrace Corporation 1136 West Evelyn Avenue Sunnyvale, CA 94086
電話：+1 626 919 3600ファックス：+1 626 919 3614メール：dan.newman@innosoft.com Mark Hoy Mainbrace Corporation 1136 West Evelyn Avenue Sunnyvale、CA 94086
tel: +1 408 774 5265
fax: +1 408 774 5290
email: mark.hoy@mainbrace.com
Jacques Bellisent SunSoft
ジャック・ベリセント・サンソフト
Phone: +1 650 786 3630
EMail: jacques.belissent@eng.sun.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。