RFC4142 日本語訳
4142 Full-mode Fax Profile for Internet Mail (FFPIM). D. Crocker, G.Klyne. November 2005. (Format: TXT=16791 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Crocker
Request for Comments: 4142 Brandenburg
Category: Standards Track G. Klyne
Nine by Nine
November 2005
コメントを求めるワーキンググループD.医者要求をネットワークでつないでください: 4142年のブランデンブルクカテゴリ: 2005年11月9日までに標準化過程G.Klyne Nine
Full-mode Fax Profile for Internet Mail (FFPIM)
インターネットメールのための完全なモードファックスプロフィール(FFPIM)
Status of This 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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
Classic facsimile document exchange represents both a set of technical specifications and a class of service. Previous work has replicated some of that service class as a profile within Internet mail. The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users.
古典的なファクシミリドキュメント交換は技術仕様書一式とサービスのクラスの両方を表します。 前の仕事はプロフィールとしてインターネット・メールの中でその何らかのサービスのクラスを模写しました。 現在の仕様はインターネットの上でファクシミリデータの「完全なモード」キャリッジを定義します、その前の仕事を当てにして、インターネット・メールのために信頼性と能力交渉を獲得するのに必要な残っている機能性を加えて、古典的なT.30ファクシミリがある平価で。 これらの付加的な機能は、規格対応することのメールインフラストラクチャとメールユーザエージェントを相互運用性の最高水準に提供するように現在ファックスユーザによって楽しまれることに近似するサービスのレベルを提供している間、設計されています。
Crocker & Klyne Standards Track [Page 1] RFC 4142 FFPIM November 2005
クロッカーとKlyne規格はFFPIM2005年11月にRFC4142を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Content Negotiation . . . . . . . . . . . . . . . . . . . . . . 3
2.1. UA-based Content Negotiation. . . . . . . . . . . . . . . . 3
2.2. ESMTP-based Content Negotiation . . . . . . . . . . . . . . 3
2.3. Interactions between UA and ESMTP Negotiation Mechanisms. . 4
3. Content Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References. . . . . . . . . . . . . . . . . . . . 5
5.2. Informative References. . . . . . . . . . . . . . . . . . . 6
A. Direct Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 満足している交渉. . . . . . . . . . . . . . . . . . . . . . 3 2.1。 UAベースの満足している交渉。 . . . . . . . . . . . . . . . 3 2.2. ESMTPベースの満足している交渉. . . . . . . . . . . . . . 3 2.3。 UAとESMTP交渉メカニズム4 3の間の相互作用。 満足している形式. . . . . . . . . . . . . . . . . . . . . . . . . 4 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 4 5。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1。 引用規格。 . . . . . . . . . . . . . . . . . . . 5 5.2. 有益な参照。 . . . . . . . . . . . . . . . . . . 6 A.のダイレクトモード。 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 B.承認. . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
1. 序論
This specification defines "full mode" carriage of facsimile data over the Internet, building upon previous work in A Simple Mode of Facsimile Using Internet Mail [RFC3965] and Extended Facsimile Using Internet Mail [RFC2532]. This specification also adds the remaining functionality necessary to achieve reliable and capable negotiation for Internet mail, on par with classic [T30] facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that closely approximates the level of service currently enjoyed by fax users.
この仕様はインターネットの上でファクシミリデータの「完全なモード」キャリッジを定義します、Facsimile Usingインターネットメール[RFC3965]とExtended Facsimile Usingインターネットメール[RFC2532]のA Simple Modeで前の仕事を当てにして。 また、この仕様はインターネット・メールのために信頼できてできる交渉を達成するのに必要な残っている機能性を加えます、古典的な[T30]ファクシミリがある平価で。 これらの付加的な機能は、規格対応することのメールインフラストラクチャとメールユーザエージェントを相互運用性の最高水準に提供するように密接に現在ファックスユーザによって楽しまれているサービスのレベルに近似するサービスのレベルを提供している間、設計されています。
Basic terminology is discussed in [RFC2542]. Implementations that conform to this specification MUST also conform to [RFC3965] and [RFC2532].
[RFC2542]で基本的な用語について議論します。 また、この仕様に従う実現は[RFC3965]と[RFC2532]に従わなければなりません。
The new features are designed to be interoperable with the existing base of mail transfer agents (MTAs) and mail user agents (MUAs), and to take advantage of existing standards for optional functionality (e.g., positive delivery confirmation and disposition notification). Enhancements described in this document utilize the existing Internet email messaging infrastructure, where possible, instead of creating fax-specific features that are unlikely to be implemented in non-fax messaging software.
新機能は、メール転送エージェント(MTAs)とメールユーザエージェント(MUAs)の存立基盤で共同利用できて、任意の機能性(例えば、積極的な配送確認と気質通知)の既存の規格を利用するように設計されています。 本書では説明された増進は可能であるところで既存のインターネットメールメッセージングインフラストラクチャを利用します、ソフトウェアを通信させながら非ファックスで実行されそうにないファックス特有の特徴を作成することの代わりに。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、中の解釈されて、説明されるとして」 「5月」、「推薦され」て、このドキュメントで「任意」があるNOT[RFC2119]はそうするべきです。
Crocker & Klyne Standards Track [Page 2] RFC 4142 FFPIM November 2005
クロッカーとKlyne規格はFFPIM2005年11月にRFC4142を追跡します[2ページ]。
2. Content Negotiation
2. 満足している交渉
Classic facsimile service is interactive, such that a sending station can discover the capabilities of the receiving station, prior to sending a facsimile of a document. This permits the sender to transmit the best quality of facsimile supported by both the sending station and the receiving station. Internet mail is store-and-forward, with potentially long latency, such that before-the-fact negotiation is problematic.
古典的なファクシミリサービスは対話的です、送付ステーションが受入れステーションの能力を発見できるように、ドキュメントのファクシミリを送る前に。 これは、送付者が送付ステーションと受入れステーションの両方によって支持されたファクシミリの最も良い品質を伝えることを許可します。 インターネット・メールが潜在的に長い潜在がある店とフォワードであるので、事実の前の交渉は問題が多いです。
Use of a negotiation mechanism permits senders to transfer a richer document form than is permitted when using the safer-but-universal default form. Without this mechanism, the sender of a document cannot be certain that the receiving station will be able to support the form.
交渉メカニズムの使用は、送付者が、より安全な、しかし、普遍的なデフォルト形式を使用するとき、受入れられるより豊かなドキュメントフォームを移すことを許可します。 このメカニズムがなければ、ドキュメントの送付者は受入れステーションがフォームを支持できるのを確信しているはずがありません。
The capabilities that can be negotiated by an FFPIM participant are specified in [RFC2534] and [RFC2879]. Implementations that are conformant to FFPIM MUST support content negotiation as described there.
FFPIM関係者が交渉できる能力は[RFC2534]と[RFC2879]で指定されます。 FFPIM MUSTへのconformantである実現はそこで説明されるように満足している交渉を支持します。
2.1. UA-based Content Negotiation
2.1. UAベースの満足している交渉
One method for exchanging the capabilities information uses a post-hoc technique, which permits an originator to send the best version known to be supported by the recipient, and to also send a better suited version if the recipient requests it. This mechanism is specified in [RFC3297]. FFPIM implementations MUST support this mechanism.
能力情報を交換するための1つの方法がポスト-hocのテクニックを使用します。(それは、創始者が受取人がそれを要求するなら、より一層合ったバージョンを受取人によって支持されて、また、送るのが知られている中で最も良いバージョンを送ることを許可します)。 このメカニズムは[RFC3297]で指定されます。 FFPIM実現はこのメカニズムをサポートしなければなりません。
2.2. ESMTP-based Content Negotiation
2.2. ESMTPベースの満足している交渉
Another method uses an ESMTP option specified in [RFC4141]. It requires support for content negotiation along the entire path the email travels. Using this mechanism, receiving ESMTP servers are able to report capabilities of the addresses (mailboxes) they support, and sending email clients are able to signal both permission and constraints on conversions.
別の方法は[RFC4141]で指定されたESMTPオプションを使用します。 それはメールが旅行する全体の経路に沿った満足している交渉に支持を要します。 このメカニズムを使用して、ESMTPを受けて、サーバはそれらがサポートするアドレス(メールボックス)の能力を報告できます、そして、送付メールクライアントは変換のときに許可と規制の両方に合図できます。
FFPIM participants MAY support this mechanism.
FFPIM関係者はこのメカニズムをサポートするかもしれません。
NOTE: This specification provides for content conversion by
unspecified intermediaries. Use of this mechanism carries
significant risk. Although intermediaries always have the ability
to perform damaging transformations, use of this specification
could result in more exploitation of that potential and,
therefore, more misbehavior. Use of intermediaries is discussed
in [RFC3238].
以下に注意してください。 この仕様は不特定の仲介者による内容変換に備えます。 このメカニズムの使用は重要な危険を伴います。 仲介者には、ダメージが大きい変化を実行する能力がいつもありますが、この仕様の使用は、その可能性の、より多くの開発をもたらして、その結果より多くの不正行為をもたらすかもしれません。 [RFC3238]で仲介者の使用について議論します。
Crocker & Klyne Standards Track [Page 3] RFC 4142 FFPIM November 2005
クロッカーとKlyne規格はFFPIM2005年11月にRFC4142を追跡します[3ページ]。
2.3. Interactions between UA and ESMTP Negotiation Mechanisms
2.3. UAとESMTP交渉メカニズムとの相互作用
FFPIM participants must ensure that their use of the UA and ESMTP methods for content negotiation is compatible. For example, two mechanisms might consult two different repositories of capabilities information, and those repositories might contain different information. Presumably, this means that at least one of these repositories is inaccurate. Therefore, the larger problem is one of correctness, rather than synchronization.
FFPIM関係者は、彼らの満足している交渉のUAとESMTP方法の使用は互換性があるのを保証しなければなりません。 例えば、2つのメカニズムが能力情報の2つの異なった倉庫に相談するかもしれません、そして、それらの倉庫は異なった情報を含むかもしれません。 おそらく、これは、少なくともこれらの倉庫の1つが不正確であることを意味します。 したがって、より大きい問題は1です。同期よりむしろ正当性について。
This specification does not require a particular method of using the mechanisms together.
この仕様はメカニズムを一緒に使用する特定の方法を必要としません。
3. Content Format
3. 満足している形式
FFPIM allows the transfer of enhanced TIFF data relative to [RFC3965] and [RFC2532]. The details for these enhancements are contained in [RFC3949]. Implementations that are conformant to FFPIM SHOULD support TIFF enhancements.
FFPIMは[RFC3965]と[RFC2532]に比例して高められたTIFFデータの転送を許容します。 これらの増進のための詳細は[RFC3949]に含まれています。 FFPIM SHOULDへのconformantである実現はTIFF増進を支持します。
It should also be noted that the content negotiation mechanism permits a sender to know the full range of content types that are supported by the recipient. Therefore, requirements for support of TIFF represent a functional minimum for FFPIM.
また、満足している交渉メカニズムが、送付者が受取人によって支持される最大限の範囲の満足しているタイプを知るのを可能にすることに注意されるべきです。 したがって、TIFFのサポートのための要件はFFPIMのために機能的な最小限を表します。
4. Security Considerations
4. セキュリティ問題
As this document is an extension of [RFC3965] and [RFC2532], the Security Considerations sections of [RFC3965] and [RFC2532] apply to this document, including discussion of PGP and S/MIME use for authentication and privacy.
このドキュメントが[RFC3965]と[RFC2532]の拡大であるので、[RFC3965]と[RFC2532]のSecurity Considerations部はこのドキュメントに適用されます、認証とプライバシーのPGPとS/MIME使用の議論を含んでいて。
It appears that the mechanisms added by this specification do not introduce new security considerations. However, the concerns raised in [RFC2532] are particularly salient for these new mechanisms.
この仕様で加えられたメカニズムが新しいセキュリティ問題を紹介しないように見えます。 しかしながら、これらの新しいメカニズムには、[RFC2532]で高められた関心は特に顕著です。
Use of this specification should occur with particular attention to the following security concerns:
この仕様の使用は以下の安全上の配慮に関する特別の注意で起こるべきです:
* Negotiation can be used as a denial of service attack.
* サービス不能攻撃として交渉を使用できます。
* Negotiation may lead to the use of an unsafe data format.
* 交渉は危険なデータの形式の使用につながるかもしれません。
* Negotiation discloses information and therefore raises privacy
concerns.
* 交渉は、情報を開示して、したがって、プライバシーの問題を提起します。
Crocker & Klyne Standards Track [Page 4] RFC 4142 FFPIM November 2005
クロッカーとKlyne規格はFFPIM2005年11月にRFC4142を追跡します[4ページ]。
Use of the ESMTP CONNEG option permits content transformation by an intermediary, along the mail transfer path. When the contents are encrypted, the intermediary cannot perform the conversion, because it is not expected to have access to the relevant secret keying material. When the contents are signed, but not encrypted, conversion will invalidate the signature. Therefore, permission to convert SHOULD NOT normally be used with signed or sealed messages.
ESMTP CONNEGオプションの使用はメール移行経路に沿った仲介者による満足している変化を可能にします。 コンテンツがコード化されているとき、仲介者は変換を実行できません、材料を合わせる関連秘密に近づく手段を持っていないと予想されるので。 内容がサインされますが、コード化されないとき、変換は署名を無効にするでしょう。 したがって、通常、SHOULD NOTを変換する許可は、サインされると共に使用されたか、またはメッセージの封をしました。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for
Content Conversion", RFC 4141, November 2005.
[RFC4141] 豊田、K.、D.クロッカー、および「内容変換のためのSMTPとMIME拡大」、RFC4141、11月2005日
[RFC3949] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
Rafferty, "File Format for Internet Fax", RFC 3949,
February 2005.
[RFC3949]バックリーとR.とヴェナブルとD.とマッキンタイヤとL.とパーソンズ、G.とJ.Rafferty、「インターネットファックスのためのファイル形式」RFC3949(2005年2月)。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2532] Masinter, L. and D. Wing, " Extended Facsimile Using
Internet Mail", RFC 2532, March 1999.
[RFC2532] Masinter、L.、およびD.は1999年3月に「拡張ファクシミリはインターネットメールを使用すること」でのRFC2532に翼をつけさせます。
[RFC2534] Masinter, L., Wing, D., Mutz, A., and K. Holtman, "Media
Features for Display, Print, and Fax", RFC 2534, March
1999.
[RFC2534]Masinter(L.)は飛んで行きます、Mutz、A.とK.Holtman、「表示、印刷、およびファックスのためのメディア機能」RFC2534、D.、1999年3月。
[RFC2542] Masinter, L., "Terminology and Goals for Internet Fax", RFC
2542, March 1999.
[RFC2542]Masinter、L.と、「インターネットファックスの用語と目標」(RFC2542)は1999を行進させます。
[RFC2879] Klyne, G. and L. McIntyre, "Content Feature Schema for
Internet Fax (V2)", RFC 2879, August 2000.
[RFC2879] KlyneとG.とL.マッキンタイヤ、「インターネットファックス(V2)のための満足している特徴図式」、RFC2879、2000年8月。
[RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content
Negotiation for Messaging Services based on Email", RFC
3297, July 2002.
[RFC3297] Klyne、G.、Iwazaki、R.、およびD.クロッカー、「メッセージサービスのためのNegotiationがメールに基礎づけた内容」、RFC3297、2002年7月。
[RFC3965] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple
Mode of Facsimile Using Internet Mail", RFC 3965, December
2004.
[RFC3965] 豊田、K.、大野、H.、村井、J.、およびD.は飛んで行きます、「ファクシミリの簡単なモードはインターネットメールを使用し」て、RFC3965、2004年12月。
Crocker & Klyne Standards Track [Page 5] RFC 4142 FFPIM November 2005
クロッカーとKlyne規格はFFPIM2005年11月にRFC4142を追跡します[5ページ]。
5.2. Informative References
5.2. 有益な参照
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[RFC3238] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
[T30] ITU-T (CCITT), "Procedures for Document Facsimile
Transmission in the General Switched Telephone Network",
Recommendation T.30, July 1996.
[T30]ITU-T(CCITT)、「一般切り換えられた電話網におけるドキュメントファクシミリ伝送のための手順」、推薦T.30、1996年7月。
Crocker & Klyne Standards Track [Page 6] RFC 4142 FFPIM November 2005
クロッカーとKlyne規格はFFPIM2005年11月にRFC4142を追跡します[6ページ]。
Appendix A. Direct Mode
付録のA.のダイレクトモード
Email is a store-and-forward service, typically with highly variable delay between the time a message leaves the sender's realm and the time it arrives in the receiver's realm. The number of relays between sender and receiver is also unknown and variable. By contrast, facsimile is generally considered to be direct and immediate.
メールはメッセージが送付者の分野を出る時、それが受信機の分野に到着する時の間には、通常、非常に可変な遅れがある店とフォワードサービスです。 送付者と受信機の間のリレーの数は、また、未知であって可変です。 対照的に、一般に、ダイレクトであって、ファクシミリが即座であると考えられます。
An email profile that fully emulates facsimile must solve several different problems. One is to ensure that the document representation semantics are faithful. Another is that the interaction between sender and receiver is similar to that of telephony-based facsimile. In particular, it must ensure the timeliness of the interaction. The specifications for FFPIM and its predecessors enable email to emulate the former, the information (semantics) activities of facsimile.
ファクシミリを完全に見習うメールプロフィールはいくつかの異なった問題を解決しなければなりません。1つはドキュメント表現意味論が確実に忠実になるようにすることになっています。 別のものは送付者と受信機との相互作用が電話ベースのファクシミリのものと同様であるということです。 特に、それは相互作用のタイムリーさであるのを確実にしなければなりません。 FFPIMのための仕様とその前任者は、メールが前者、ファクシミリの情報(意味論)活動を見習うのを可能にします。
The ESMTP CONNEG option sets the stage for achieving the latter, with email-based facsimile transfer that has interactive negotiations, on a par with telephony-based facsimile. The key, additional requirement is to achieve timeliness. Ultimately, timeliness requires configuring sender and receiver email servers to interact directly. The sender's MTA must directly contact the receiver's MTA. With typical email service configurations, the content and interaction semantics of facsimile can be emulated quite well, but timeliness cannot be assured.
ESMTP CONNEGオプションは後者を達成するために舞台装置をセットします、対話的な交渉を持っているメールベースのファクシミリ転送で、電話ベースのファクシミリがある平価で。 主要で、追加している要件はタイムリーさであるのを達成することです。 結局、タイムリーは、直接相互作用するように送付者と受信機Eメールサーバを構成するのを必要とします。 送付者のMTAは直接受信機のMTAに連絡しなければなりません。 典型的なメールサービス構成で、ファクシミリの内容と相互作用意味論を全くよく見習うことができますが、タイムリーさであるのを保証できません。
To achieve direct sending, the originating MTA must not use sending-side intermediaries such as outbound enterprise MTAs. Instead, it must be configured to do transmissions directly to hosts specified in email addresses, based on queries to the public DNS. To achieve direct receiving, the target MTAs must have DNS A records, without MX records. That is, they also must be configured not to use intermediaries.
直送を達成するために、由来しているMTAは外国行きの企業MTAsなどの発信サイド仲介者を使用してはいけません。 代わりに、直接Eメールアドレスで指定されたホストにトランスミッションをするのは構成していなければなりません、公共のDNSへの質問に基づいて。 ダイレクト受信を達成するために、目標MTAsには、DNS A記録がMX記録なしでなければなりません。 また、仲介者を使用しないようにすなわち、それらを構成しなければなりません。
The sender may then use ESMTP Conneg to determine the capabilities of the receiver. Afterwards the sender will use the capabilities information to tailor the TIFF message content it sends.
次に、送付者は、受信機の能力を決定するのにESMTP Connegを使用するかもしれません。その後、送付者は、それが送るTIFFメッセージ内容を合わせるのに能力情報を使用するでしょう。
Crocker & Klyne Standards Track [Page 7] RFC 4142 FFPIM November 2005
クロッカーとKlyne規格はFFPIM2005年11月にRFC4142を追跡します[7ページ]。
Appendix B. Acknowledgements
付録B.承認
The IETF Fax working group, in collaboration with the IETF and the ITU, has diligently participated in a multi-year effort to produce Internet-based emulation of classic facsimile via email profiles. The effort benefited from the group's willingness to provide an initial, minimal mechanism, and then develop the specification to include more facsimile features as implementation and operation experience was gained.
IETFとITUとの共同では、IETFファックスワーキンググループはまめにメールプロフィールを通して古典的なファクシミリのインターネットを利用するエミュレーションを作成するためのマルチ年の努力に参加しました。 努力は、実現と操作経験をするのに従って、より多くのファクシミリ機能を含むように初期の、そして、最小量のメカニズムを提供して、次に仕様を開発するグループの意欲の利益を得ました。
Authors' Addresses
作者のアドレス
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA
デーヴ医者ブランデンブルクインターネットワーキング675はDriveカリフォルニア94086サニーベル(米国)を小綺麗にします。
Phone: +1.408.246.8253 EMail: dcrocker@bbiw.net
以下に電話をしてください。 +1.408 .246 .8253 メール: dcrocker@bbiw.net
Graham Klyne Nine by Nine UK
グラハムKlyne9時9分前イギリス
Phone: EMail: GK-IETF@ninebynine.org
以下に電話をしてください。 メール: GK-IETF@ninebynine.org
Crocker & Klyne Standards Track [Page 8] RFC 4142 FFPIM November 2005
クロッカーとKlyne規格はFFPIM2005年11月にRFC4142を追跡します[8ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Crocker & Klyne Standards Track [Page 9]
クロッカーとKlyne標準化過程[9ページ]
一覧
スポンサーリンク
