[要約] RFC 4612は、T.38プロトコルのためのMIMEサブタイプであるaudio/t38の登録に関するものです。このRFCの目的は、T.38プロトコルを使用してリアルタイムのファクシミリ通信を実現するためのMIMEタイプの標準化と登録を行うことです。
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
リアルタイムファクシミリ（T.38） - オーディオ/T38 MIMEサブタイプの登録
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).
Copyright（c）The Internet Society（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）を定義しています。1つのオプションとして、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をFAXシグナル伝達のトランスポートとして使用するための理論的根拠を提供し、上記のシグナリングに関連付けられた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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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年に最初に承認されたとき、UDP（RTPではなくUDP輸送層（UDPTL）を使用）を介して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を使用すると、IETF内の冗長性[12]、ヘッダー圧縮[13] [14]、およびその他のRTP関連作業を活用できます。RTPを使用して、udptlとは対照的に、輸送用に、RTPを知っており、理解している幅広いデバイスとの相互運用性が向上します。これには、ファイアウォール、ネットワークアドレス変換（NAT）デバイス、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データは、2つの公開された電話ネットワーク（PSTN）ネットワークを橋渡しするゲートウェイによって生成されているため、オーディオからファックスへの移行が同じメディアストリーム内で発生することを期待するのは非常に自然です。その理由は、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はT.38 [1]を修正して、RTPを使用してT.38を輸送できるようにしました。それに伴い、同じRTPセッション内でT.38をオーディオとともに切り替えることができるようにするには、新しいMIME登録（Audio/T38）が必要です。
One new MIME type and associated RTP payload format has been registered, by the IANA as described below.
以下に説明するように、IANAによって1つの新しいMIMEタイプと関連するRTPペイロード形式が登録されています。
To: ietf-types@iana.org Subject: Registration of Standard MIME media type audio/t38
宛先：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.
レート：RTPタイムスタンプ時計レート。これは8000Hzでなければなりません。クロック周波数は任意の値に設定される場合がありますが、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」または「転送されたtcf」です。このパラメーターは、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：フェーズC（[6]を参照）、非ECMデータに充填ビットを取り外して挿入する機能を示し、帯域幅を減らします。これはブールパラメーターです（inclusion = true、explusion = false）。このパラメーターは、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からライン形式に変換する能力を示します。これはブールパラメーターです（inclusion = true、explusion = false）。このパラメーターは、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に出会う能力を示します。これはブールパラメーターです（inclusion = true、explusion = false）。このパラメーターは、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 recのバージョン番号です。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 [8]、SIP [9]、およびH.248 [7]システムのコンテキスト内で、RTPを超えるT.38のキャリッジの手順、構文、およびパラメーターを定義しています。
Published specification:
公開された仕様：
ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", September 2005
ITU-T推奨T.38、「IPネットワークを介したリアルタイムグループ3ファクシミリ通信の手順」、2005年9月
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
Real-time facsimile (fax)
リアルタイムファクシミリ（ファックス）
Additional information:
追加情報：
Magic number(s): File extension(s): Macintosh File Type Code(s):
マジック番号：ファイル拡張子：Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Paul E. Jones paulej@packetizer.com
Paul E. Jones Paulej@packetizer.com
Intended usage: 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タイプ（ "Audio"）は、メディア名として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の操作を修飾するために、必要ないくつかのパラメーターを定義します。これらは、RFC 3555 [5]、セクション2で定義されているように使用されます。パラメーターは、SDPで定義された「A = FMTP」パラメーターを使用して、「パラメーター」または「パラメーター=値」のペアのセミコロン分離リストとして提供されます。[2];「パラメーター」形式は、存在が「真」で「false」に等しく、ブール値に使用されます。
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
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構成に関しては、FAXペイロードは80ビットより短いHMAC-SHA1認証タグを使用しないでください。
[1] ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", September 2005.
[1] ITU-T推奨T.38、「IPネットワークを介したリアルタイムグループ3ファクシミリ通信の手順」、2005年9月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley、M。and 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.、Frederick、R。、およびV. Jacobson、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、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.、McGrew、D.、Naslund、M.、Carrara、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] Perkins、C.、et al。、「冗長なオーディオデータの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. Jacobson、「低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[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] Koren、T.、Casner、S.、Geevarghese、J.、Thompson、B。、およびP. Ruddy、「高い遅延、パケット損失、並べ替えを伴うリンクのための圧縮RTP（CRTP）の強化」、RFC 3545、2003年7月。
Authors' Addresses
著者のアドレス
Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709, USA
Paul E. Jones Cisco Systems、Inc。7025 Kit Creek Rd。研究Triangle Park、NC 27709、米国
Phone: +1 919 392 6948
EMail: paulej@packetizer.com
Hiroshi Tamura Ricoh Company, LTD. 1-3-6 Nakamagome, Ohta-ku, Tokyo 143-8555 Japan
Hiroshi Tamura Ricoh Company、Ltd。1-3-6 Nakamagome、Ohta-Ku、東京143-8555日本
Phone: +81-3-3777-8124
Fax: +81-3-5742-8859
EMail: tamura@cs.ricoh.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。