RFC3965 日本語訳

Network Working Group                                          K. Toyoda
Request for Comments: 3965                                       H. Ohno
Obsoletes: 2305                                                 J. Murai
Category: Standards Track                                   WIDE Project
                                                                 D. Wing
                                                                   Cisco
                                                           December 2004

コメントを求めるワーキンググループK.豊田の要求をネットワークでつないでください: 3965時間大野は以下を時代遅れにします。 2305年のJ.村井カテゴリ: プロジェクトD.翼のコクチマス2004年12月に広い標準化過程

             A Simple Mode of Facsimile Using Internet Mail

インターネットメールを使用するファクシミリの簡単なモード

Status of this Memo

この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 (2004).

Copyright(C)インターネット協会(2004)。

Abstract

要約

   This specification provides for "simple mode" carriage of facsimile
   data using Internet mail.  Extensions to this document will follow.
   The current specification employs standard protocols and file formats
   such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail
   Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile.
   It can send images not only to other Internet-aware facsimile devices
   but also to Internet-native systems, such as PCs with common email
   readers which can handle MIME mail and TIFF for Facsimile data.  The
   specification facilitates communication among existing facsimile
   devices, Internet mail agents, and the gateways which connect them.

インターネット・メールを使用することでこの仕様はファクシミリデータの「簡単なモード」キャリッジに備えます。 このドキュメントへの拡大は続くでしょう。 Facsimileのための現在の仕様雇用のTCP/IPなどの標準プロトコルとファイル形式、インターネット・メールプロトコル、マルチパーパスインターネットメールエクステンション(MIME)、およびTagged Image File Format(TIFF)。 それは他のインターネット意識しているファクシミリデバイスに送るだけではなく、ネイティブのインターネットシステムにもイメージを送ることができます、一般的なメール読者がいるFacsimileデータのためにMIMEメールとTIFFを扱うことができるPCなどのように。 仕様は既存のファクシミリデバイス、インターネット・メールエージェント、およびそれらを接続するゲートウェイの中でコミュニケーションを容易にします。

   This document is a revision of RFC 2305.  There have been no
   technical changes.

このドキュメントはRFC2305の改正です。 技術変化が全くありませんでした。

1. Introduction

1. 序論

   This specification defines message-based facsimile communication over
   the Internet.  It describes a minimum set of capabilities, taking
   into account those of typical facsimile devices and PCs that can
   generate facsimile data.

この仕様はメッセージベースのファクシミリインターネット通信を定義します。 それは最小の能力について説明します、典型的なファクシミリデバイスとファクシミリデータを生成することができるPCのものを考慮に入れて。

Toyoda, et al.              Standards Track                     [Page 1]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[1ページ]RFC3965の標準化過程

   A G3Fax device has substantial restrictions due to specifications in
   the standards, such as for timers.  This specification defines a
   profile for Internet mail, rather than creating a distinct "facsimile
   over the Internet" service.  The semantics resulting from the profile
   are designed to be compatible with facsimile operation over the
   general switched telephone network, so that gateways between
   facsimile and Internet mail can operate with very high fidelity.

G3Faxデバイスには、タイマなどの規格における仕様によるかなりの制限があります。 この仕様は「インターネットの上のファクシミリ」異なったサービスを作成するよりむしろインターネット・メールのためのプロフィールを定義します。 プロフィールから生じる意味論は一般的な切り換えられた電話網の上のファクシミリ操作と互換性があるように設計されています、ファクシミリとインターネット・メールの間のゲートウェイが非常に高い信義で作動できるように。

   The reason for developing this capability as an email profile is to
   permit interworking amongst facsimile and email users.  For example,
   it is intended that existing email users be able to send normal
   messages to lists of users, including facsimile-based recipients, and
   that other email recipients shall be able to reply to the original
   and continue to include facsimile recipients.  Similarly, it is
   intended that existing email software work without modification and
   not be required to process new, or different data structures, beyond
   what is normal for Internet mail users.  Existing email service
   standards are used, rather than replicating mechanisms which are more
   tailored to existing facsimile standards, to ensure this
   compatibility with existing email service.

メールプロフィールとしてこの能力を見いだす理由はファクシミリとメールの中でユーザを織り込むことを許可することです。 例えば、既存のメールユーザがファクシミリベースの受取人を含むユーザのリストに正常なメッセージを送ることができて、他のメール受取人がオリジナルに答えて、ずっとファクシミリ受取人を含むことができるだろうことを意図します。 同様に、存在は変更なしでソフトウェア仕事をメールして、新しいか、異なったデータ構造を処理するのに必要でないことを意図します、インターネット・メールユーザにとって、正常なことを超えて。 既存のメールサービス規格は、既存のメールサービスとのこの互換性を確実にするのに既存のファクシミリ規格にさらに適合するメカニズムを模写するよりむしろ使用されます。

1.1. Services

1.1. サービス

   A facsimile-capable device that uses T.4 [15] and the general
   switched telephone network (GSTN) is called a "G3Fax device" in this
   specification.  An "IFax device" is an Internet-accessible device
   capable of sending, receiving or forwarding Internet faxes.  A
   message can be sent to an IFax device using  an Internet mail
   address.  A message can be sent to a G3Fax device  using an Internet
   mail address; the message MAY be forwarded via an IFax offramp
   gateway.

T.4[15]と一般的な切り換えられた電話網を使用するファクシミリできるデバイスはこの仕様による「G3Faxデバイス」と呼ばれます(GSTN)。 「IFaxデバイス」はインターネットファックスを送るか、受け止めるか、または進めることができるインターネットアクセスしやすいデバイスです。 インターネット郵便の宛先を使用することでIFaxデバイスにメッセージを送ることができます。 インターネット郵便の宛先を使用することでG3Faxデバイスにメッセージを送ることができます。 IFax出口ランプゲートウェイを通してメッセージを転送するかもしれません。

1.2. Cases

1.2. ケース

   This specification provides for communication between each of the
   following combinations:

この仕様はそれぞれの以下の組み合わせのコミュニケーションに備えます:

   Internet mail             =>  Network printer
   Internet mail             =>  Offramp gateway (forward to
                                 G3Fax)
   Network scanner           =>  Network printer
   Network scanner           =>  Offramp gateway (forward to
                                 G3Fax)
   Network scanner           =>  Internet mail

インターネット・メール=>Networkプリンタインターネット・メール=>Offrampゲートウェイ(G3Faxに前進の)ネットワークスキャナ=>NetworkプリンタNetworkスキャナ=>Offrampゲートウェイ(G3Faxに前進の)ネットワークスキャナ=>インターネットメール

Toyoda, et al.              Standards Track                     [Page 2]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[2ページ]RFC3965の標準化過程

1.3. Key Words

1.3. キーワード

   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 [13].

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

2. Communication Protocols

2. 通信プロトコル

   The set of conventions necessary to achieve facsimile-compatible
   service covers basic data transport, document data formats, message
   (document) addressing, delivery confirmation, and message security.
   In this section, the first 4 are covered.  The remainder are covered
   in following sections, along with additional details for addressing
   and formats.

ファクシミリコンパチブルサービスを達成するのに必要なコンベンションのセットは基礎データ輸送、ドキュメントデータ形式、メッセージ(ドキュメント)アドレシング、配送確認、およびメッセージセキュリティを含んでいます。 このセクションでは、最初の4はカバーされています。 残りはアドレシングと形式のための追加詳細に伴う以下の章でカバーされています。

2.1. Transport

2.1. 輸送

   This section describes mechanisms involved in the transport between
   IFAX devices.

このセクションはIFAXデバイスの間の輸送にかかわるメカニズムについて説明します。

2.1.1. Relay

2.1.1. リレー

   Data transfer MAY be achieved using standard Internet mail transfer
   mechanisms [1, 3].  The format of addresses MUST conform to the RFC
   821 <addr-spec> and RFC 822 <mailbox> Internet mail standards [1, 2,
   3].

データ転送は達成された使用標準のインターネット・メールトランスファ・メカニズムであるかもしれません[1、3]。 アドレスの形式は>とRFC822<メールボックス>インターネット・メール規格[1、2、3]をRFC821<addr-仕様に従わせなければなりません。

2.1.2. Gateway

2.1.2. ゲートウェイ

   A gateway translates between dissimilar environments.  For IFax, a
   gateway connects between Internet mail and the T.4/GSTN facsimile.
   Gateways can service multiple T.4/GSTN facsimile users or can service
   only one.  In the former case, they serve as a classic "mail transfer
   agent" (MTA) and in the latter as a classic "mail user agent" (UA).
   An onramp is a gateway which connects from T.4/GSTN facsimile to
   Internet mail.  An offramp is a gateway which connects from Internet
   mail to T.4/GSTN facsimile. Behavior of onramps is out of scope for
   this specification.

ゲートウェイは異なった環境の間で翻訳されます。 IFaxに関しては、ゲートウェイはインターネット・メールとT.4/GSTNファクシミリの間で接続します。 ゲートウェイは、複数のT.4/GSTNファクシミリユーザにサービスを提供できるか、または1つしか修理できません。 前の場合では、それらは古典的な「メールユーザエージェント」(UA)として古典的な「メール転送エージェント」(MTA)と後者で機能します。 入口ランプはT.4/GSTNファクシミリからインターネット・メールまで接続するゲートウェイです。 出口ランプはインターネット・メールからT.4/GSTNファクシミリまで接続するゲートウェイです。 この仕様のための範囲の外に入口ランプの振舞いがあります。

Toyoda, et al.              Standards Track                     [Page 3]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[3ページ]RFC3965の標準化過程

   This specification describes the Internet mail service portion of
   offramp addressing, confirmation and failure notification.  Details
   are provided in later sections.

この仕様は出口ランプアドレシング、確認、および失敗通知のインターネット・メールサービス部分について説明します。 詳細は後のセクションで明らかにされます。

2.1.3. Mailbox protocols

2.1.3. メールボックスプロトコル

   An offramp gateway that operate as an MTA serving multiple users
   SHOULD use SMTP; a gateway that operates as a UA serving a single
   mail recipient MAY use a mailbox access protocol such as POP [6] or
   similar mailbox access protocols.

複数のユーザSHOULDに役立つMTAとして作動する出口ランプゲートウェイはSMTPを使用します。 ただ一つのメール受取人5月の使用にPOP[6]などのメールボックスアクセス・プロトコルに役立つか、または同様のメールボックスアクセスにプロトコルに役立つUAとして作動するゲートウェイ。

   NOTE: An offramp gateway that relays mail based on addressing
   information needs to ensure that it uses addresses supplied in the
   MTA envelope, rather than from elsewhere, such as addresses listed in
   the message content headers.

以下に注意してください。 アドレス指定情報に基づくメールをリレーする出口ランプゲートウェイは、ほかの場所からというよりむしろMTA封筒で供給されたアドレスを使用するのを保証する必要があります、メッセージ内容ヘッダーに記載されたアドレスなどのように。

2.2. Formats

2.2. 形式

2.2.1. Headers

2.2.1. ヘッダー

   IFax devices MUST be compliant with RFC 2822 and RFC 1123, which
   define the format of mail headers.  The header of an IFax message
   SHOULD include Message-ID and MUST include all fields required by [2,
   3], such as DATE and FROM.

IFaxデバイスはRFC2822とRFC1123と共に言いなりになっているに違いありません。(RFCはメールヘッダの書式を定義します)。 SHOULDが必要な状態でMessage-IDを含んでいて、すべての分野を含まなければならないというDATEやFROMなどのIFaxメッセージ[2、3]のヘッダー。

2.2.2. MIME

2.2.2. MIME

   IFax devices MUST be compliant with MIME [4], except as noted in
   Appendix A.

Appendix Aに述べられるのを除いて、IFaxデバイスはMIME[4]で言いなりになっているに違いありません。

2.2.3. Content

2.2.3. 内容

   The data format of the facsimile image is based on the minimum set of
   TIFF for Facsimile [5], also known as the S profile.   Such facsimile
   data are included in a MIME object by use of the image/TIFF sub-type
   [12].  Additional rules for the use of TIFF for Facsimile, for the
   message-based Internet facsimile application, are defined later.

ファクシミリイメージのデータの形式は、Facsimile[5]のためにTIFFの最小のセットに基づいていて、また、Sプロフィールとして知られています。 そのようなファクシミリデータはMIMEオブジェクトにTIFFサブイメージ/タイプ[12]の使用で含まれています。 TIFFのFacsimileの使用、メッセージベースのインターネットファクシミリアプリケーションのための付則は後で定義されます。

2.2.4. Multipart

2.2.4. 複合

   A single multi-page document SHOULD be sent as a single multi- page
   TIFF file, even though recipients MUST process multipart/mixed
   containing multiple TIFF files. If multipart content is present and
   processing of any part fails, then processing for the entire message
   is treated as failing, per [Processing failure] below.

ただ一つのマルチページTIFFファイルとして独身のマルチページドキュメントSHOULDを送って、受取人は複合の、または、混ぜられた含有を処理しなければなりませんが、複数のTIFFがファイルします。 複合内容が存在していて、どんな部分の処理も失敗するなら、全体のメッセージのための処理は失敗として扱われます、以下の[処理失敗]単位で。

Toyoda, et al.              Standards Track                     [Page 4]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[4ページ]RFC3965の標準化過程

2.3. Error Handling

2.3. エラー処理

2.3.1. Delivery failure

2.3.1. 配信障害

   This section describes existing requirements for Internet mail,
   rather than indicating special requirements for IFax devices.

このセクションはIFaxデバイスのための特別な要件を示すよりむしろインターネット・メールのための既存の要件について説明します。

   In the event of relay failure, the sending relay MUST generate a
   failure message, which SHOULD be in the format of a DSN [9].

リレーの故障の場合、送付リレーは失敗メッセージを生成しなければなりません。

   NOTE:  Internet mail transported via SMTP MUST contain a MAIL FROM
          address appropriate for delivery of return notices.  (See
          section 5.2.6.)

以下に注意してください。 SMTP MUSTを通して輸送されたインターネット・メールはリターン通知の配送に、適切なMAIL FROMアドレスを含んでいます。 (セクション5.2.6を見てください。)

2.3.2. Processing Failure

2.3.2. 処理失敗

   IFax devices with limited capabilities might be unable to process the
   content of a message.  If this occurs it is important to ensure that
   the message is not lost without any notice.  Notice MAY be provided
   in any appropriate fashion, and the exact handling is a local matter.
   (See Appendix A, second bullet.)

限られた能力があるIFaxデバイスはメッセージの内容を処理できないかもしれません。 これが起こるなら、メッセージが少しも予告なしで失われていないのを保証するのは重要です。 どんな適切なファッションにも通知を提供するかもしれません、そして、正確な取り扱いは地域にかかわる事柄です。 (Appendix A、2番目の弾丸を見てください。)

3. Addressing

3. アドレシング

3.1. Classic Email Destinations

3.1. 古典的なメールの目的地

   Messages being sent to normal Internet mail recipients will use
   standard Internet mail addresses, without additional constraints.

普通のインターネット・メール受取人に送られるメッセージは追加規制なしで標準のインターネット郵便の宛先を使用するでしょう。

3.2. G3Fax Devices

3.2. G3Faxデバイス

   G3Fax devices are accessed via an IFAX offramp gateway, which
   performs any authorized telephone dial-up.

G3FaxデバイスはIFAX出口ランプゲートウェイを通してアクセスされます。ゲートウェイはどんな認可された電話ダイヤルアップも実行します。

3.3. Address Formats Used by Offramps

3.3. 出口ランプによって使用されるアドレス形式

   When a G3Fax device is identified by a telephone number, the entire
   address used for the G3fax device, including the number and offramp
   host reference MUST be contained within standard Internet mail
   transport fields, such as RCPT TO and MAIL FROM [1, 3].  The address
   MAY be contained within message content fields, such as <authentic>
   and <destination> [2, 3], as appropriate.

G3Faxデバイスが電話番号、G3faxデバイスに使用される全体のアドレスによって特定されるとき、標準のインターネット・メール輸送分野の中に数と出口ランプホスト指示するものを含んでいるのを保管しなければなりません、RCPT TOやMAIL FROM[1、3]のように。 アドレスは<の正統の>や<の目的地>[2、3]のように適切なメッセージ内容分野の中に保管されるかもしれません。

   As for all Internet mail addresses, the left-hand-side (local-part)
   of an address is not to be interpreted except by the MTA that is
   named on the right-hand-side (domain).

すべてのインターネットのような郵便の宛先、正しい手のサイド(ドメイン)で命名されるMTA以外に、アドレスの左側(地方の部分)を解釈してはいけません。

Toyoda, et al.              Standards Track                     [Page 5]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[5ページ]RFC3965の標準化過程

   The telephone number format SHOULD conform to [7, 8].  Other formats
   MUST be syntactically distinct from [7, 8].

電話番号形式SHOULDは[7、8]に従います。 他の形式は[7、8]とシンタクス上異なっていなければなりません。

4. Image File Format

4. 画像ファイル形式

   Sending IFax devices MUST be able to write minimum set TIFF files,
   per the rules for creating minimum set TIFF files defined in TIFF for
   Facsimile (the S profile) [5], which is also compatible with the
   specification for the minimum subset of TIFF-F in [14].  Receiving
   IFax devices MUST be able to read minimum set TIFF files.

送付IFaxデバイスは最小のセットTIFFファイルを書くことができなければなりません、また、[14]でTIFF-Fの最小の部分集合のための仕様と互換性があるFacsimile(Sプロフィール)[5]のためにTIFFで定義された最小のセットTIFFファイルを作成するための規則単位で。 IFaxデバイスを受けると、最小のセットTIFFファイルを読むことができなければなりません。

   A sender SHOULD NOT use TIFF fields and values beyond the minimum
   subset of TIFF for Facsimile unless the sender has prior knowledge of
   other TIFF fields or values supported by the recipient.  The
   mechanism for determining capabilities of recipients is beyond the
   scope of this document.

送付者が受取人に他のTIFF分野か値に関する先の知識をサポートさせない場合、TIFFがFacsimileのためにTIFFの最小の部分集合を超えてさばいて、評価する送付者SHOULD NOT使用。 受取人の能力を決定するためのメカニズムはこのドキュメントの範囲を超えています。

5. Security Considerations

5. セキュリティ問題

5.1. General Directive

5.1. 一般指示

   This specification is based on use of existing Internet mail.  To
   maintain interoperability with Internet mail, any security to be
   provided should be part of the of the Internet security
   infrastructure, rather than a new mechanism or some other mechanism
   outside of the Internet infrastructure.

この仕様は既存のインターネット・メールの使用に基づいています。 提供されるどんなセキュリティもインターネット・メールがある相互運用性を維持するためには、部分であるべきである、新しいメカニズムか外のある他のメカニズムよりむしろインターネット基盤のインターネットセキュリティインフラストラクチャについて。

5.2. Threats and Problems

5.2. 脅威と問題

   Both Internet mail and G3Fax standards and operational services have
   their own set of threats and countermeasures.  This section attends
   only to the set of additional threats which ensue from integrating
   the two services.  This section reviews relevant concerns about
   Internet mail for IFax environments, as well as considering the
   potential problems which can result of integrating the existing G3Fax
   service with Internet mail.

インターネット・メールとG3Fax規格と操作上のサービスの両方には、それら自身の脅威と対策のセットがあります。 このセクションは2つのサービスを統合するので続く追加脅威のセットだけに気を配ります。 このセクションは結果として生じることができる既存のG3Faxサービスをインターネット・メールと統合する潜在的な問題を考えることと同様にIFax環境のためのインターネット・メールに関する関連心配を見直します。

5.2.1. Spoofed Sender

5.2.1. 送付者であると偽造されます。

   The actual sender of the message might not be the same as that
   specified in the Sender or From fields of the message content headers
   or the MAIL FROM address from the SMTP envelope.

メッセージの実際の送付者はメッセージ内容ヘッダーのSenderかFrom分野かSMTP封筒からのMAIL FROMアドレスで指定されたそれと同じでないかもしれません。

   In a tightly constrained environment, sufficient physical and
   software controls may be able to ensure prevention of this problem.
   The usual solution is through encryption-based authentication, either
   for the channel or associated with the object, as discussed below.

しっかり強制的な環境で、物理的、そして、ソフトウェアの十分な制御装置はこの問題の防止を確実にすることができるかもしれません。 普通のソリューションは、以下で議論するように暗号化ベースの認証と、どちらかチャンネルのためにあるか、またはオブジェクトに関連しています。

Toyoda, et al.              Standards Track                     [Page 6]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[6ページ]RFC3965の標準化過程

   It should be recognized that SMTP implementations do not provide
   inherent authentication of the senders of messages, nor are sites
   under obligation to provide such authentication.  End-to-end
   approaches such as S/MIME and PGP/MIME are currently being developed
   within the IETF.  These technologies can provide such authentication.

SMTP実装がメッセージの送付者の固有の認証を提供しないで、そのような認証を提供する義務の下のサイトであると認められるべきです。 S/MIMEやPGP/MIMEなどの終わりから終わりへのアプローチは現在、IETFの中で開発されています。 これらの技術はそのような認証を提供できます。

5.2.2. Resources Consumed by Dialout

5.2.2. ダイヤルアウトによって消費されたリソース

   In addition to the resources normally consumed for email (CPU cycles
   and disk), offramp facsimile causes an outdial which often imposes
   significant resource consumption, such as financial cost.  Techniques
   for establishing authorization of the sender are essential to those
   offramp facsimile services that need to manage such consumption.

通常、メール(CPUサイクルとディスク)のために消費されたリソースに加えて、出口ランプファクシミリはしばしば重要なリソース消費を課す「外-ダイヤル」を引き起こします、財政的な費用などのように。 送付者の承認を確立するためのテクニックはそのような消費を管理する必要があるそれらの出口ランプファクシミリサービスに不可欠です。

   Due to the consumption of these resources by dialout, unsolicited
   bulk email which causes an outdial is undesirable.

ダイヤルアウトによるこれらのリソースの消費のために、「外-ダイヤル」を引き起こす求められていない大量のメールは望ましくありません。

   Offramp gateways SHOULD provide the ability to authorize senders in
   some manner to prevent unauthorized use of the offramp.  There are no
   standard techniques for authorization using Internet protocols.

出口ランプゲートウェイSHOULDは、出口ランプの無断使用を防ぐために何らかの方法で送付者に権限を与える能力を提供します。 インターネットプロトコルを使用する承認のためのどんな標準のテクニックもありません。

   Typical solutions use simple authentication of the originator to
   establish and verify their identity and then check the identity
   against a private authorization table.

典型的なソリューションは、個人的な承認テーブルに対して設立する創始者の簡易認証を使用して、彼らのアイデンティティについて確かめて、次に、アイデンティティをチェックします。

   Originator authentication entails the use of weak or strong
   mechanisms, such as cleartext keywords or encryption-based
   data-signing, respectively, to determine and validate the identify
   of the sender and assess permissions accordingly.

創始者認証が決定して、有効にするためにそれぞれcleartextキーワードか暗号化ベースのデータ署名などの弱いか強いメカニズムの使用を伴う、それに従って、許容を送付者に特定して、評価してください。

   Other control mechanisms which are common include source filtering
   and originator authentication.  Source filtering entails offramp
   gateway verification of the host or network originating the message
   and permitting or prohibiting relaying accordingly.

他の一般的な制御機構はソースフィルタリングと創始者認証を含んでいます。 ソースフィルタリングはそれに従って、リレーするのをメッセージを溯源して、許可するか、または禁止するホストかネットワークの出口ランプゲートウェイ検証を伴います。

5.2.3. GSTN Authorization Information

5.2.3. GSTN承認情報

   Confidential information about the sender necessary to dial a G3Fax
   recipient, such as sender's calling card authorization number, might
   be disclosed to the G3Fax recipient (on the cover page), such as
   through parameters encoded in the G3Fax recipients address in the To:
   or CC: fields.

送付者のテレホンカード承認番号などのG3Fax recipientにダイヤルするのに必要な送付者に関する秘密情報はG3Fax recipient(カバーページの)に明らかにされるかもしれません、To:のG3Fax recipientsアドレスでコード化されたパラメタなどのように または、CC: 分野。

   Senders SHOULD be provided with a method of preventing such
   disclosure.  As with mechanisms for handling unsolicited faxes, there
   are not yet standard mechanisms for protecting such information.

送付者SHOULD、そのような公開を防ぐメソッドを提供してください。 求められていないファックスを扱うためのメカニズムのように、そのような情報を保護するための標準のメカニズムがまだありません。

Toyoda, et al.              Standards Track                     [Page 7]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[7ページ]RFC3965の標準化過程

   Out-of-band communication of authorization information or use of
   encrypted data in special fields are the available non-standard
   techniques.

バンドの外では、承認情報に関するコミュニケーションか特別な分野での暗号化されたデータの使用が利用可能な標準的でないテクニックです。

   Typically authorization needs to be associated to specific senders
   and specific messages, in order to prevent a "replay" attack which
   causes and earlier authorization to enable a later dial-out by a
   different (and unauthorized) sender.  A non-malicious example of such
   a replay would be to have an email recipient reply to all original
   recipients -- including an offramp IFax recipient -- and have the
   original sender's authorization cause the reply to be sent.

通常、承認は、特定の送付者と特定のメッセージに関連づけられる必要があって、「再生」を防いで、どの原因と以前の承認を攻撃するか、そして、異なって(権限のない)の送付者で後のダイヤルアウトを可能にしてください。 そのような再生の非悪意がある例はメール受取人が出口ランプIFax受取人を含んでいて、すべてのオリジナルの受取人に答えて、元の送り主の承認で回答を送らせるのを持つだろうことです。

5.2.4. Sender Accountability

5.2.4. 送付者責任

   In many countries, there is a legal requirement that the "sender" be
   disclosed on a facsimile message.  Email From addresses are trivial
   to fake, so that using only the MAIL FROM [1, 3]  or From [2, 3]
   header is not sufficient.

多くの国に、「送付者」がファクシミリメッセージで明らかにされるという法的必要条件があります。 メールFromアドレスは見せかけるために些細です、MAIL FROM[1、3]かFrom[2、3]ヘッダーだけを使用するのが十分でないように。

   Offramps SHOULD ensure that the recipient is provided contact
   information about the offramp, in the event of problems.

出口ランプSHOULDは、出口ランプに関する問い合わせ先が問題の場合、受取人に提供されるのを確実にします。

   The G3Fax recipient SHOULD be provided with sufficient information
   which permits tracing the originator of the IFax message.  Such
   information might include the contents of the MAIL FROM, From, Sender
   and Reply-To headers, as well as Message-Id and Received headers.

G3Fax recipient SHOULD、IFaxメッセージの創始者をつけることを許可する十分な情報を提供してください。 そして、そのような情報はMAIL FROMのコンテンツを含むかもしれません、From、Sender、Reply、-、ヘッダー、Message-イド、およびReceivedヘッダー。

5.2.5. Message Disclosure

5.2.5. メッセージ公開

   Users of G3Fax devices have an expectation of a level of message
   privacy which is higher than the level provided by Internet mail
   without security enhancements.

G3Faxデバイスのユーザには、セキュリティ増進なしでインターネット・メールによって提供されたレベルより高いメッセージプライバシーのレベルへの期待があります。

   This expectation of privacy by G3Fax users SHOULD be preserved as
   much as possible.

この期待、G3FaxユーザSHOULDによるプライバシーでは、できるだけ保存されてください。

   Sufficient physical and software control may be acceptable in
   constrained environments.  The usual mechanism for ensuring data
   confidentially entail encryption, as discussed below.

物理的、そして、ソフトウェアの十分な制御装置は強制的な環境で許容できるかもしれません。 以下で議論するようにデータが秘密に暗号化を伴うのを確実にするための普通のメカニズム。

5.2.6. Non Private Mailboxes

5.2.6. 非個人的なメールボックス

   With email, bounces (delivery failures) are typically returned to the
   sender and not to a publicly-accessible email account or printer.
   With facsimile, bounces do not typically occur.  However, with IFax,
   a bounce could be sent elsewhere (see section [Delivery Failure]),
   such as a local system administrator's account, publicly-accessible
   account, or an IFax printer (see also [Traffic Analysis]).

メールで、公的にアクセスしやすいメールアカウントかプリンタではなく、送付者に弾み(配信障害)を通常返します。 ファクシミリで、弾みは通常起こりません。 しかしながら、IFaxと共に、弾みをほかの場所に送ることができました(セクション[配送Failure]を見てください)、ローカルシステムアドミニストレータのアカウント、公的にアクセスしやすいアカウント、またはIFaxプリンタ(また[トラフィックAnalysis]、見る)などのように。

Toyoda, et al.              Standards Track                     [Page 8]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[8ページ]RFC3965の標準化過程

5.2.7. Traffic Analysis

5.2.7. トラヒック分析

   Eavesdropping of senders and recipients is easier on the Internet
   than GSTN.  Note that message object encryption does not prevent
   traffic analysis, but channel security can help to frustrate attempts
   at traffic analysis.

インターネットでは、送付者と受取人の盗聴はGSTNより簡単です。 メッセージオブジェクト暗号化がトラヒック分析を防ぎませんが、チャンネルセキュリティが、トラヒック分析への試みをだめにするのを助けることができることに注意してください。

5.3. Security Techniques

5.3. セキュリティのテクニック

   There are two basic approaches to encryption-based security which
   support authentication and privacy:

認証とプライバシーをサポートする暗号化ベースのセキュリティへの2つの基本的なアプローチがあります:

5.3.1. Channel Security

5.3.1. チャンネルセキュリティ

   As with all email, an IFax message can be viewed as it traverses
   internal networks or the Internet itself.

すべてのメールなら、内部のネットワークかインターネット自体を横断するとき、IFaxメッセージを見ることができます。

   Virtual Private Networks (VPN), encrypted tunnels, or transport layer
   security can be used to prevent eavesdropping of a message as it
   traverses such networks.  It also provides some protection against
   traffic analysis, as described above.

そのようなネットワークを横断するのでメッセージを盗み聞くのを防ぐのに仮想の兵士のNetworks(VPN)、暗号化されたトンネル、またはトランスポート層セキュリティを使用できます。 また、それは上で説明されるようにトラヒック分析に対する何らかの保護を提供します。

   At the current time various protocols exist for performing the above
   functions, and are only mentioned here for information.  Such
   protocols are IPSec [17] and TLS [18].

上の機能を実行するために現在の時間様々なプロトコルで存在していて、情報のためにここに言及されるだけです。 そのようなプロトコルは、IPSec[17]とTLS[18]です。

5.3.2. Object Security

5.3.2. オブジェクトセキュリティ

   As with all email, an IFax message can be viewed while it resides on,
   or while it is relayed through, an intermediate Mail Transfer Agent.

それを住んでいるか、またはゆったり過ごしている間、すべてのメールなら、IFaxメッセージを見ることができる、通じてリレーされる、中間的メール配達エージェント。

   Message encryption can be used to provide end-to-end encryption.

終端間暗号化を提供するのにメッセージ暗号化を使用できます。

   At the current time two protocols are commonly used for message
   encryption and are only mentioned here for information.  The two
   protocols are PGP-MIME [16] and S/MIME [19].

現在の時間に、2つのプロトコルしか、メッセージ暗号化に一般的に使用されて、情報のためにここに言及されません。 2つのプロトコルが、PGP-MIME[16]とS/MIME[19]です。

6. References

6. 参照

6.1. Normative References

6.1. 引用規格

   [1]  Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821,
        April 2001.

[1]Klensin、J.、エディタ、「簡単なメール転送プロトコル」、RFC2821、2001年4月。

   [2]  Resnick, P., Editor, "Internet Message Format", RFC 2822, April
        2001.

[2] レズニック、P.、エディタ、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

Toyoda, et al.              Standards Track                     [Page 9]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[9ページ]RFC3965の標準化過程

   [3]  Braden, R., "Requirements for Internet hosts - application and
        support", STD 3, RFC 1123, October 1989.

[3] ブレーデンと、R.と、「インターネット・ホスト--アプリケーションのための要件とサポート」、STD3、RFC1123、10月1989日

   [4]  Borenstein, N. and N. Freed, "Multipurpose Internet Mail
        Extensions (MIME) Part Five: Conformance Criteria and Examples",
        RFC 2049, November 1996.

[4] Borenstein、N.、およびN.フリード、「マルチパーパスインターネットメールエクステンション(MIME)は5を分けます」。 「順応評価基準と例」、RFC2049、11月1996日

   [5]  Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
        Rafferty, "File Format for Internet Fax", RFC 3949, November
        2004.

[5] バックリーとR.とヴェナブルとD.とマッキンタイヤとL.とパーソンズ、G.とJ.Rafferty、「インターネットファックスのためのファイル形式」RFC3949(2004年11月)。

   [6]  Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
        53, RFC 1939, May 1996.

[6] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」

   [7]  Allocchio, C., "Minimal GSTN address format for Internet mail",
        RFC 3191, October 2001.

[7]Allocchio、C.、「インターネット・メールのための最小量のGSTNアドレス形式」、RFC3191、2001年10月。

   [8]  Allocchio, C., "Minimal fax address format for Internet mail",
        RFC 3192, October 2001.

[8]Allocchio、C.、「インターネット・メールのための最小量のファックスアドレス形式」、RFC3192、2001年10月。

   [9]  Moore, K., and G. Vaudreuil, "An Extensible Message Format for
        Delivery Status Notifications", RFC 3464, January 2003.

[9] ムーア、K.、およびG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。

   [10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November
        1996.

解放された[10]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。

   [11] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part
        Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
        November 1996.

[11] ムーア、K. 「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。

   [12] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) -
        image/tiff MIME Sub-type Registration", RFC 3302, September
        2002.

[12] パーソンズとG.とJ.Rafferty、「Image File Format(TIFF)にタグ付けをしてください--イメージ/いさかいMIMEはRegistrationをSubタイプする」RFC3302、2002年9月。

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

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

6.2. Informative References

6.2. 有益な参照

   [14] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) -- F
        Profile for Facsimile", RFC 2306, March 1998.

[14] パーソンズ、G.、およびJ.Rafferty、「画像ファイル形式(いさかい)にタグ付けをしてください--ファクシミリのためのFプロフィール」、RFC2306、3月1998日

   [15] ITU-T (CCITT), "Standardization of Group 3 facsimile apparatus
        for document transmission", ITU-T (CCITT), Recommendation T.4.

[15] ITU-T(CCITT)、「ドキュメントトランスミッションのためのGroup3ファクシミリ装置の規格化」、ITU-T(CCITT)、Recommendation T.4。

Toyoda, et al.              Standards Track                    [Page 10]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[10ページ]RFC3965の標準化過程

   [16] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP
        Message Format", RFC 2440, November 1998.

[16] カラスとJ.とDonnerhackeとL.とフィニー、H.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。

   [17] Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

[17] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

   [18] Hoffman, P., "SMTP Service Extension for Secure SMTP over
        Transport Layer Security", RFC 3207, February 2002.

[18] ホフマン、P.、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、RFC3207、2002年2月。

   [19] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
        2633, June 1999.

[19]Ramsdell、B.、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。

7. Acknowledgements

7. 承認

   This specification was produced by the Internet Engineering Task
   Force Fax Working Group, over the course of more than one year's
   online and face-to-face discussions.  As with all IETF efforts, many
   people contributed to the final product.

この仕様はインターネット・エンジニアリング・タスク・フォースファックス作業部会によって作り出されました、1年以上間のオンラインの、そして、面と向かっている議論の過程の上で。 すべてのIETF取り組みのように、多くの人々が完成品に貢献しました。

   Active for this document were: Steve Huston, Jeffrey Perry, Greg
   Vaudreuil, Richard Shockey, Charles Wu, Graham Klyne, Robert A.
   Rosenberg, Larry Masinter, Dave Crocker, Herman Silbiger, James
   Rafferty.

このドキュメントにアクティブであるのは、以下の通りでした。 スティーブ・ヒューストン、ジェフリーPerry、グレッグ・ボードルイ、リチャード・ショッキー、チャールズ・ウー、グラハムKlyne、ロバート・A.ローゼンバーグ、ラリーMasinter、デーヴ・クロッカー、ハーマンSilbiger(ジェームスRafferty)。

Toyoda, et al.              Standards Track                    [Page 11]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[11ページ]RFC3965の標準化過程

Appendix A:  Exceptions to MIME

付録A: まねる例外

   * IFax senders are not required to be able to send text/plain
     messages (RFC 2049 requirement 4), although IFax  recipients are
     required to accept such messages, and to process them.

* IFax送付者はテキスト/明瞭なメッセージ(RFC2049要件4)を送る必要はないことができます、IFax受取人が、そのようなメッセージを受け入れて、それらを処理しなければなりませんが。

   * IFax recipients are not required to offer to put results in a file.
     (Also see 2.3.2.)

* IFax受取人は、ファイルに結果を入れると申し出る必要はありません。 (また、.2に2.3を見ます)

   * IFax recipients MAY directly print/fax  the received message rather
     than "display" it, as indicated in RFC 2049.

* IFax受取人は、RFC2049にみられるようにそれを「表示する」より受信されたメッセージを直接むしろ印刷するか、またはファックスで送るかもしれません。

Appendix B:  List of edits to RFC 2305

付録B: RFC2305への編集のリスト

   +----+----------+-------------------------------------------------+
   | No.| Section  |             Edit  July 27, 2001                 |
   +----+----------+-------------------------------------------------+
   | 1. |Copyright | Updated copyright from "1998" to "1999,2000"    |
   |    |Notice    |                                                 |
   +----+----------+-------------------------------------------------+
   | 2. |SUMMARY   | Changed the phrase "over the Internet" to       |
   |    |          |               "using Internet mail"             |
   +----+----------+-------------------------------------------------+
   | 3. |5         | Changed the paragraphs regarding to the         |
   |    |          | following references to make them very          |
   |    |          | non-normative.                                  |
   |    |          |  "OpenPGP Message Format", RFC 2440             |
   |    |          |  "Security Architecture for the IP", RFC 2401   |
   |    |          |  "SMTP Service Extensions for Secure SMTP over  |
   |    |          |   TLS", RFC 2487                                |
   |    |          |  "S/MIME Version 2 Message Specification",      |
   |    |          |   RFC 2311                                      |
   +----+----------+-------------------------------------------------+
   | 4. |REFERENCES| Removed the following references because they   |
   |    |          | are non-normative                               |
   |    |          |  "SMTP Service Extensions for Delivery Status   |
   |    |          |   Notifications", RFC 1891                      |
   |    |          |  "Internet Message Access Protocol", RFC 2060   |
   +----+----------+-------------------------------------------------+
   | 5. |REFERENCES| Separated REFERENCES to the normative and       |
   |    |          | non-normative                                   |
   +----+----------+-------------------------------------------------+
   | 6. |Appendix  | Changed the phrase from "NOT REQUIRED" to       |
   |    | A        | "not required"                                  |
   +----+----------+-------------------------------------------------+
   | 7. |Appendix  | Added "Appendix B  List of edits to RFC 2305"   |
   +----+----------+-------------------------------------------------+

+----+----------+-------------------------------------------------+ | いいえ| セクション| 2001年7月27日を編集してください。| +----+----------+-------------------------------------------------+ | 1. |著作権| アップデートされた「1998」から「1999、2000」までの著作権| | |通知| | +----+----------+-------------------------------------------------+ | 2. |概要| 「インターネット」という句を変えます。| | | | 「インターネット・メールを使用します」| +----+----------+-------------------------------------------------+ | 3. |5 | パラグラフ関係を変えます。| | | | それらをまさしくそのであるするように参照に続きます。| | | | 非規範的です。 | | | | 「OpenPGPメッセージ・フォーマット」、RFC2440| | | | 「IPのためのセキュリティー体系」、RFC2401| | | | 「SMTPは安全なSMTPのための拡大を修理します」| | | | 「TLS」、RFC2487| | | | 「S/MIMEバージョン2メッセージ仕様」| | | | RFC2311| +----+----------+-------------------------------------------------+ | 4. |参照| 以下の参照を取り除く、それら| | | | 非規範的です。| | | | 「配送状態のためのSMTPサービス拡張子」| | | | 「通知」、RFC1891| | | | 「インターネットメッセージアクセス・プロトコル」、RFC2060| +----+----------+-------------------------------------------------+ | 5. |参照| そして標準への切り離されたREFERENCES。| | | | 非規範的です。| +----+----------+-------------------------------------------------+ | 6. |付録| 「NOTが必要であること」からの句を変えます。| | | A| 「必要ではありません」| +----+----------+-------------------------------------------------+ | 7. |付録| 加えられた「RFC2305への編集の付録B List」| +----+----------+-------------------------------------------------+

Toyoda, et al.              Standards Track                    [Page 12]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[12ページ]RFC3965の標準化過程

Authors' Addresses

作者のアドレス

   Kiyoshi Toyoda
   Panasonic Communications Co., Ltd.
   4-1-62 Minoshima Hakata-ku
   Fukuoka 812-8531 Japan

812-8531 パナソニックのコミュニケーション株式会社4-1-62Minoshima博多区の福岡日本の豊田清

   Fax:   +81 92 477 1389
   EMail: toyoda.kiyoshi@jp.panasonic.com

Fax: +81 92 477 1389はメールされます: toyoda.kiyoshi@jp.panasonic.com

   Hiroyuki Ohno
   National Institute of Information and Communications Technology
   4-2-1, Nukui-Kitamachi, Koganei, Tokyo,
   184-8795, Japan

情報通信技術4-2-1のヒロユキ大野Nationalの研究所、Nukui-Kitamachi、小金井、東京184-8795、日本

   Fax:   +81 42 327 7941
   EMail: hohno@ohnolab.org

Fax: +81 42 327 7941はメールされます: hohno@ohnolab.org

   Jun Murai
   Keio University
   5322 Endo, Fujisawa
   Kanagawa 252 Japan

6月の村井慶応義塾大学5322の遠藤、神奈川日本藤沢252

   Fax:   +81 466 49 1101
   EMail: jun@wide.ad.jp

Fax: +81 466 49 1101はメールされます: jun@wide.ad.jp

   Dan Wing
   170 W. Tasman Drive
   San Jose, CA 95134 USA

ダン翼の170w.タスマンDriveサンノゼ、カリフォルニア95134米国

   Phone: +1 408 525 5314
   EMail: dwing@cisco.com

以下に電話をしてください。 +1 5314年の408 525メール: dwing@cisco.com

Toyoda, et al.              Standards Track                    [Page 13]

RFC 3965               A Simple Mode of Facsimile          December 2004

豊田、他 ファクシミリ2004年12月の簡単なモードあたり[13ページ]RFC3965の標準化過程

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(C)インターネット協会(2004)。

   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 IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。

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

Toyoda, et al.              Standards Track                    [Page 14]

豊田、他 標準化過程[14ページ]