Network Working Group P. Jones
Request for Comments: 4612 Cisco Systems, Inc.
Category: Historic H. Tamura
Ricoh Company, LTD.
August 2006
Real-Time Facsimile (T.38) - audio/t38
MIME Sub-type Registration
Status of This Memo
このメモのステータス
This memo defines a Historic Document 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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document defines the MIME sub-type audio/t38. The usage of this MIME type, which is intended for use within Session Description Protocol (SDP), is specified within ITU-T Recommendation T.38.
この文書は、MIMEサブタイプオーディオ/ T38を定義します。セッション記述プロトコル（SDP）内での使用のために意図され、このMIMEタイプの使用は、ITU-T勧告T.38内で指定されています。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Mechanisms for Transporting T.38 over an IP Network .............2
4. IANA Considerations .............................................3
5. SDP Mapping of MIME Parameters ..................................5
6. Security Considerations .........................................6
7. Normative References ............................................6
8. Informative References ..........................................6
ITU-T Recommendation T.38 [1] defines the Internet Facsimile Protocol (IFP) for carriage of facsimile data over IP networks. As one option, IFP packets may be carried within an RTP [3] stream, either as the only content within the media stream or switched with other audio payload types.
ITU-T勧告T.38 [1] IPネットワーク上でファクシミリデータのキャリッジのためのインターネットファックスプロトコル（IFP）を定義します。一つの選択肢として、IFPパケットは、メディア・ストリーム内のコンテンツのみのいずれかと、RTP [3]は、ストリーム内で搬送され得るか、または他のオーディオペイロードタイプと切り替えます。
This memo provides rationale for using RTP as a transport for fax signaling and specifies the MIME type associated with said signaling.
このメモは、ファックスシグナリングのためのトランスポートとしてRTPを使用するための理論的根拠を提供し、関連付けられたMIMEタイプがシグナリングを前記指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[4]。
When T.38 was first approved in 1998, it allowed for the transport of T.38 via UDP (using UDP Transport Layer (UDPTL), rather than RTP) or TCP. As of the time of this publication, UDPTL is the predominant means for transporting T.38 data over an IP network. In support of that, RFC 3362 [11] was published in order to allow devices to signal their desire to use UDPTL to transport T.38.
T.38は、最初に1998年に承認されたとき、それは、またはTCP（UDPトランスポートではなくRTPよりも層（UDPTL）を、使用して）UDPを介したT.38の輸送を可能にしました。この出版物の時点では、UDPTLは、IPネットワーク上でT.38データを転送するための有力な手段です。そののサポートでは、RFC 3362 [11]のデバイスはT.38を輸送するUDPTLを使用するために自分の欲望を合図することを可能にするために出版されました。
A number of issues were raised with respect to the usage of UDPTL for the long-term, though. Specifically, there were concerns over the fact that UDPTL does not provide the same kind of statistics reporting as RTP Control Protocol (RTCP). Further, there are no procedures in place for encrypting and protecting the integrity of the UDPTL stream. While the latter could be addressed in UDPTL, doing so would require a lot of effort and would largely be a duplication of the security work already completed within the IETF; e.g., Secure RTP (SRTP) [10].
多くの問題は、しかし、長期のためのUDPTLの使用に関して提起されました。具体的には、UDPTLは、RTP制御プロトコル（RTCP）などの統計レポートの同じ種類を提供していないということへの懸念がありました。さらに、暗号化とUDPTLストリームの完全性を保護するための場所には手順がありません。後者はUDPTLで対処することができますが、そうすることは多くの労力を必要とし、大部分はすでにIETF内に完了し、セキュリティの作業の重複になります。例えば、セキュアRTP（SRTP）[10]。
There are clear advantages in using RTP for T.38 today. For example, using RTP allows one to take advantage of the redundancy [12], header compression [13][14], and other RTP-related work within the IETF. Using RTP, as opposed to UDPTL, for transport provides better interoperability with a wider range of devices that know and understand RTP. This includes applications such as firewalls, Network Address Translation (NAT) devices, and gateways that bridge two IP networks, which generally support RTP before most other real-time media.
今日T.38のためにRTPを使用する際の明確な利点があります。例えば、RTPを使用して、1つはIETF内の冗長性[12]、ヘッダー圧縮[13] [14]、及び他のRTP関連の作業を利用することを可能にします。トランスポートがRTPを知っていると理解してデバイスの広い範囲で優れた相互運用性を提供するために、UDPTLとは反対に、RTPを使用しました。これは、ファイアウォール、ネットワークアドレス変換（NAT）デバイス、およびゲートウェイ一般的に他のほとんどのリアルタイムメディアの前にRTPをサポートするブリッジ2つのIPネットワーク、などのアプリケーションが含まれています。
Lastly, since today most T.38 data is generated by gateways that bridge two Public Switched Telephone Network (PSTN) networks, it is quite natural to expect that the transition from audio to fax should happen within the same media stream. The reason is that the T.38 data is simply an alternative representation of information received on the PSTN circuit. If the T.38 data is encapsulated in RTP, the gateways can easily transition from audio to fax and back again and can simply use the payload type to indicate the type of media that it is currently transmitting.
最後に、以来、今日最もT.38データは、公衆交換電話網（PSTN）交換ネットワークブリッジ2つのゲートウェイによって生成され、ファックスするオーディオからの移行は、同じメディア・ストリーム内で発生する必要があることを期待するのは当然です。その理由は、T.38データは単にPSTN回路で受信された情報の代替表現であることです。 T.38データがRTPにカプセル化されている場合、ゲートウェイは容易に再びファックスやオーディオから移行することができるし、単にそれが現在送信しているメディアのタイプを示すためにペイロードタイプを使用することができます。
With these considerations in mind, the ITU-T amended T.38 [1] to allow RTP to be used to transport T.38. With that, a new MIME registration (audio/t38) is needed to allow for T.38 to be switched along with audio within the same RTP session.
これらを考慮すると、ITU-Tは、[1] RTPは、T.38を輸送するために使用することができるようにT.38を改正しました。それによって、新しいMIME登録（オーディオ/ T38）は、同じRTPセッション内のオーディオと一緒に切り換えることがT.38を可能にするために必要とされます。
One new MIME type and associated RTP payload format has been registered, by the IANA as described below.
以下に説明するように、1つの新しいMIMEタイプと関連するRTPペイロードフォーマットは、IANAによって、登録されています。
To: ietf-types@iana.org Subject: Registration of Standard MIME media type audio/t38
To：ietf-types@iana.org件名：標準のMIMEメディアタイプのオーディオ/ T38の登録
MIME media type name: audio
MIMEメディアタイプ名：オーディオ
MIME subtype name: t38
MIMEサブタイプ名：T38
Required parameters:
必須パラメータ：
rate: The RTP timestamp clock rate, which SHOULD be 8000Hz. The clock frequency MAY be set to any value, but it SHOULD be set to the same value as that for any audio packets in the same RTP stream in order to avoid RTP timestamp rate switching.
レート：8000HzであるべきであるRTPタイムスタンプのクロックレート、。クロック周波数は任意に設定することができるが、それは、RTPタイムスタンプレート切り替えを避けるために、同一のRTPストリーム内の任意のオーディオパケットと同じ値に設定する必要があります。
T38FaxRateManagement: Indicates the fax rate management model as defined in T.38. Values may be "localTCF" or "transferredTCF". This parameter is defined in ITU-T Recommendation T.38.
T38FaxRateManagement：T.38で定義されたファックスレート管理モデルを示します。値は「localTCF」または「transferredTCF」であってもよいです。このパラメータは、ITU-T勧告T.38で定義されています。
Optional parameters:
オプションのパラメータ：
T38FaxFillBitRemoval: Indicates the capability to remove and insert fill bits in Phase C (refer to [6]), non-ECM data to reduce bandwidth. This is a boolean parameter (inclusion = true, exclusion = false). This parameter is defined in ITU-T Recommendation T.38.
T38FaxFillBitRemoval：帯域幅を低減するために、非ECMデータ（[6]を参照）を除去し、相Cのビットを埋める挿入する能力を示します。これは、ブール・パラメータ（封入=真、除外=偽）です。このパラメータは、ITU-T勧告T.38で定義されています。
T38FaxTranscodingMMR: Indicates the ability to convert to/from MMR from/to the line format for increasing the compression of the data and reducing the bandwidth in the packet network. This is a boolean parameter (inclusion = true, exclusion = false). This parameter is defined in ITU-T Recommendation T.38.
T38FaxTranscodingMMRは：/からのデータの圧縮を増加し、パケットネットワークにおける帯域幅を削減するためのライン形式にする/ MMRから変換する能力を示します。これは、ブール・パラメータ（封入=真、除外=偽）です。このパラメータは、ITU-T勧告T.38で定義されています。
T38FaxTranscodingJBIG: Indicates the ability to convert to/from JBIG to reduce bandwidth. This is a boolean parameter (inclusion = true, exclusion = false). This parameter is defined in ITU-T Recommendation T.38.
T38FaxTranscodingJBIGは：帯域幅を減らすためにJBIGから/に変換する能力を示します。これは、ブール・パラメータ（封入=真、除外=偽）です。このパラメータは、ITU-T勧告T.38で定義されています。
T38FaxVersion: This is the version number of ITU-T Rec. T.38. New versions shall be compatible with previous versions. Absence of this parameter indicates version 0. The version is expressed as an integer value. This parameter is defined in ITU-T Recommendation T.38.
T38FaxVersion：これは、ITU-T勧告のバージョン番号です。 T.38。新しいバージョンは、以前のバージョンとの互換性がなければなりません。このパラメータが存在しない場合は、バージョンを整数値として表現されているバージョン0を示しています。このパラメータは、ITU-T勧告T.38で定義されています。
T38FaxMaxBuffer: Indicates the maximum number of octets that can be stored on the remote device before an overflow condition occurs. It is the responsibility of the transmitting application to limit the transfer rate to prevent an overflow. The negotiated data rate should be used to determine the rate at which data is being removed from the buffer. Value is an integer. This parameter is defined in ITU-T Recommendation T.38.
T38FaxMaxBufferは：オーバーフロー状態が発生する前に、リモート・デバイス上に格納することができるオクテットの最大数を示します。オーバーフローを防止するために、転送速度を制限するために、送信アプリケーションの責任です。ネゴシエートされたデータレートは、データがバッファから除去される速度を決定するために使用されるべきです。値は整数です。このパラメータは、ITU-T勧告T.38で定義されています。
T38FaxMaxDatagram: The maximum size of the payload within an RTP packet that can be accepted by the remote device. This is an integer value. This parameter is defined in ITU-T Recommendation T.38.
T38FaxMaxDatagram：リモートデバイスによって受け入れられるRTPパケット内のペイロードの最大サイズ。これは、整数値です。このパラメータは、ITU-T勧告T.38で定義されています。
Encoding considerations:
エンコードの考慮事項：
The encoding of the IFP RTP packets is defined in ITU-T Recommendation T.38. This sub-type is not intended for use with e-mail.
IFP RTPパケットの符号化は、ITU-T勧告T.38で定義されています。このサブタイプは、電子メールを使用するためのものではありません。
Security considerations:
セキュリティの考慮事項：
See Section 6 of RFC 4612.
RFC 4612のセクション6を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
ITU-T Recommendation T.38 defines the procedures, syntax, and parameters for the carriage of T.38 over RTP within the context of H.323 [8], SIP [9], and H.248 [7] systems.
ITU-T勧告T.38は、H.323のコンテキスト内の手順、構文、及びRTP上T.38のキャリッジのためのパラメータを定義する[8]、SIP [9]、およびH.248 [7]のシステム。
Published specification:
公開された仕様：
ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", September 2005
、2005年9月ITU-T勧告T.38、「IPネットワーク上のリアルタイムグループ3ファクシミリ通信のための手順」
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
Real-time facsimile (fax)
リアルタイムファクシミリ（FAX）
Additional information:
追加情報：
Magic number(s): File extension(s): Macintosh File Type Code(s):
マジックナンバー（S）：ファイルの拡張子（S）：Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Paul E. Jones paulej@packetizer.com
ポール・E.ジョーンズpaulej@packetizer.com
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Paul E. Jones
著者/変更コントローラ：ポール・E.・ジョーンズ
The MIME information described in Section 4 is utilized in SDP in order to establish T.38 media streams. Specifically:
セクション4で説明MIME情報がT.38メディアストリームを確立するためにSDPに利用されます。具体的に：
o The MIME type ("audio") goes in SDP "m=" as the media name.
O MIMEタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
o The MIME subtype ("t38") goes in SDP "a=rtpmap" as the encoding name.
O MIMEサブタイプ（ "T38"）は、符号化名としてSDPの "a = rtpmap" に進みます。
o The parameter "rate" also goes in "a=rtpmap" as clock rate.
Oパラメータ「率」も、クロックレートとして「A = rtpmap」になります。
The MIME type defines several required and optional parameters to qualify the operation of T.38; these are to be used as defined in RFC 3555 [5], Section 2. The parameters are provided as a semi-colon separated list of "parameter" or "parameter=value" pairs using the "a=fmtp" parameter defined in SDP [2]; the "parameter" form is used for boolean values, where presence equals "true" and absence "false".
MIMEタイプは、T.38の動作を修飾するために、いくつかの必須およびオプションのパラメータを定義します。これらは、定義されたように[5]、第2パラメータは、「パラメータ」のセミコロンで区切られたリストまたはSDPで定義された「A =のfmtp」パラメータを使用して「パラメータ=値」のペアとして提供されるRFC 3555で使用されます[2]。 「パラメータ」フォームには存在が「真」と不在「偽」に等しいブール値、のために使用されています。
Consider the following example, which describes a media stream that allows the transport of G.711 audio and T.38 fax information:
G.711オーディオおよびT.38ファックス情報の輸送を可能にするメディアストリームを記述する次の例を考えてみます。
m=audio 6800 RTP/AVP 0 98 a=rtpmap:98 t38/8000 a=fmtp:98 T38FaxVersion=2;T38FaxRateManagement=transferredTCF
M =オーディオ6800 RTP / AVP 0 98 = rtpmap：98 T38 / 8000 =のfmtp：98 T38FaxVersion = 2; T38FaxRateManagement = transferredTCF
T.38 is vulnerable to attacks that are common to other types of RTP and SRTP payloads. However, unlike audio, T.38 data may be manipulated in ways that are more obtrusive than audio. For example, rogue packets may cause transmission failure, and manipulated packets may alter terminal identity.
T.38は、RTPとSRTPペイロードの他のタイプに共通している攻撃に対して脆弱です。しかし、オーディオとは異なり、T.38データは、音声よりも目障りな方法で操作することができます。例えば、不正なパケットは送信失敗を引き起こす可能性があり、および操作パケットは、端末識別情報を変更することができます。
The security considerations discussed in the RTP specification and any applicable RTP profile (for example, [10]) are applicable to T.38. Regarding SRTP configuration, fax payloads SHOULD NOT use an HMAC-SHA1 authentication tag that is shorter than 80 bits.
RTP仕様で議論したセキュリティ問題と該当RTPプロファイル（例えば、[10]）T.38に適用可能です。 SRTP構成については、ファックスペイロードは、80ビットよりも短いHMAC-SHA1認証タグを使用しないでください。
[1] ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", September 2005.
[1]、2005年9月ITU-T勧告T.38、 "IPネットワーク上のリアルタイムグループ3ファクシミリ通信のための手順"。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[5] Casner、S.とP. Hoschka、 "RTPペイロード形式のMIMEタイプ登録"、RFC 3555、2003年7月。
[6] ITU-T Recommendation T.30, "Procedures for document facsimile transmission in the general switched telephone network", July 2003.
[6] ITU-T勧告T.30は、2003年7月、「一般的に、文書ファクシミリ伝送のための手順は、交換電話網」。
[7] ITU-T Recommendation H.248, "Gateway Control Protocol", May 2002.
[7] ITU-T勧告H.248、 "ゲートウェイ制御プロトコル"、2002年5月。
[8] ITU-T Recommendation H.323, "Packet-based multimedia communications systems", May 2003.
[8] ITU-T勧告H.323、 "パケットベースのマルチメディア通信システム"、2003年5月。
[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[9]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[10] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[10] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[11] Parsons, G., "Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration", RFC 3362, August 2002.
[11]パーソンズ、G.、 "リアルタイムファクシミリ（T.38） - 画像/ T38のMIMEサブタイプ登録"、RFC 3362、2002年8月。
[12] Perkins, C., et al., "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[12]パーキンス、C.、ら、 "冗長オーディオデータのRTPペイロード"、RFC 2198、1997年9月。
[13] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[13] Casner、S.とV.ヤコブソン、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[14] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003.
[14]コレン、T.、Casner、S.、Geevarghese、J.、トンプソン、B.、およびP.ルディ、 "強化された圧縮RTP（CRTP）高遅延、パケットロス・順序付きリンクの"、RFC 3545、 2003年7月。
Authors' Addresses
著者のアドレス
Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709, USA
ポール・E.ジョーンズシスコシステムズ社7025キットクリークRdを。リサーチトライアングルパーク、NC 27709、USA
Phone: +1 919 392 6948 EMail: paulej@packetizer.com
電話：+1 919 392 6948 Eメール：paulej@packetizer.com
Hiroshi Tamura Ricoh Company, LTD. 1-3-6 Nakamagome, Ohta-ku, Tokyo 143-8555 Japan
ひろし たむら りこｈ こｍぱｎｙ、 ＬＴＤ。 １ー３ー６ なかまごめ、 おｈたーく、 ときょ １４３ー８５５５ じゃぱん
Phone: +81-3-3777-8124 Fax: +81-3-5742-8859 EMail: tamura@cs.ricoh.co.jp
電話：+ 81-3-3777-8124ファックス：+ 81-3-5742-8859 Eメール：tamura@cs.ricoh.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。